UNIVERSIDAD CENTRAL DE VENEZUELA

FACULTAD DE CIENCIAS
ESCUELA DE COMPUTACION

TRABAJO ESPECIAL DE GRADO

Prototipo de un sistema de Workflow en lnea
utilizando Software Libre para Oficinas de
Computacin. Caso de Estudio: Instituto de Urbanismo
de la Facultad de Arquitectura y Urbanismo de la
Universidad Central de Venezuela.

Realizado por:
Hayde I Camacho L
C.I.: 6.136.945
Jos Rafael Mendoza
C.I.: 7.921.693
Caracas, Abril de 2007

Introduccin

Capitulo I
Introduccin
El Instituto de Urbanismo de la Universidad Central de Venezuela, cumple
funciones docentes a travs de los postgrados, cursos de ampliacin de
conocimientos, maestras y doctorados. Funciones de investigacin gracias a
los proyectos realizados por los profesores de planta y funciones de extensin
realizadas a travs de la empresa universitaria Insurbeca, C.A.; que desarrolla
proyectos urbanos contratados por terceros y en los cuales emplea los
conocimientos adquiridos en las funciones de investigacin y extensin.
Para desarrollar las actividades docentes, el Instituto de Urbanismo posee una
Sala de Estudiantes con quince computadoras y un proyector; un Taller de
Diseo, con una computadora y un proyector, dos computadoras porttiles y
proyectores, que sern utilizados por los profesores que dictan ctedra fuera
de las instalaciones de la institucin.
En lo que a investigacin se refiere, los docentes de planta cuentan con un
computador en cada puesto de trabajo y una Sala de Trabajo para los
asistentes de investigacin.
Adems, la empresa Insurbeca cuenta con tres Salas de Proyectos dotadas de
computadoras equipadas con suficiente plataforma tecnolgica para cubrir las
necesidades
de
software
que
tienen
los
proyectos
desarrollados
(principalmente herramientas CAD Computer Assisted Design y base de datos,
as como de herramientas bsicas de oficina).
Para complementar todas estas actividades, el Instituto cuenta con Unidades
de Apoyo, como la Biblioteca, dotada con cuatro computadoras que soportan
aplicaciones de consulta bibliogrfica; Servicio de Fotocopiado y Escaneo de
documentos; la Unidad de Publicaciones, que da soporte a la realizacin de
libros y dems documentos de difusin; y la Unidad de Computacin, que
presta todo el servicio de soporte tcnico y operativo para que todas las
unidades funcionen con la excelencia esperada.
La Unidad de Computacin est integrada por un grupo de servidores (uno de
impresin, dos de archivos, y uno de correo y pginas web); la sala de
impresiones (conformada por dos impresoras lser a color, dos impresoras
lser en negro, y un plotter de gran formato); y una plataforma de red
(conformada por cerca de cien puntos de red estructurada, ocho switches y un
enrutador que presta servicios de traduccin de direcciones de red o NAT (para
poder utilizar hasta 256 computadoras con una sola direccin IP), as como
asignacin de direcciones dinmicas o DHCP. Adems, la Oficina de
Computacin supervisa las conexiones a Internet; una a travs de la red
corporativa de la UCV y la otra gracias a un servicio contratado de banda
ancha.
I

Introduccin

Es de hacer notar que toda esta plataforma tecnolgica se ha conseguido

gracias a los aportes provenientes del Centro de Desarrollo Cientfico y
Humanstico (CDCH) quien financia las actividades de investigacin y docencia
a travs de ayudas institucionales, el Fondo Nacional de Ciencia y Tecnologa
(FONACIT) y el aporte de la Facultad de Arquitectura y Urbanismo a travs de
la partida presupuestaria ordinaria para infraestructura. Igualmente, la
empresa Insurbeca, dedica parte de sus ingresos al mantenimiento y
actualizacin de la plataforma tecnolgica de la institucin.
Por todo lo anterior, se dice que el Instituto de Urbanismo de la UCV posee una
plataforma tecnolgica apropiada para el desarrollo de investigaciones urbanas
y geogrficas como las que realiza.
Como consecuencia de esto, aparecen necesidades y problemas inherentes al
uso de este tipo de tecnologas de informacin. Desde el punto de vista
tcnico, la Oficina de Computacin es el mecanismo mediante el cual la
plataforma tecnolgica del IU se mantiene operativa, a travs de procesos
preventivos y correctivos (soporte) que permiten garantizar la continuidad
operativa de los servicios tecnolgicos. Ahora bien, los aspectos tcnicos estn
divididos en tres reas, que comprenden en primer lugar las estaciones de
trabajo que son las computadoras de uso individual de los miembros de la
institucin, las cuales requieren soporte continuo en sitio; en segundo lugar,
los componentes de red, servidores de archivos, de impresin, de correo,
impresoras de red y trazadores (plotters) que requieren constante
mantenimiento, respaldo y mejoras para prestar servicio continuo; y por
ltimo, la infraestructura de red que va desde puntos de red, cableado y
enrutadores (routers) y conmutadores (switches) funcionales.
Por otro lado, los procesos administrativos incluyen, entre otras funciones,
asegurar los equipos adquiridos, preparar las solicitudes para actualizacin y
adquisicin de equipos, tramitar las reparaciones de los equipos, bien sea a
travs del seguro o por medio de solicitud de reparacin generada por los
entes de financiacin, y la administracin de licencias del software en uso.
Haciendo un anlisis de las actividades desarrolladas por la Oficina de
Computacin del Instituto de Urbanismo de la Facultad de Arquitectura y
Urbanismo de la Universidad Central de Venezuela, se encuentra, que pueden
ser automatizadas a travs de la Tecnologa de Workflow con un Sistema en
Lnea.
Recapitulando, entre las funciones de la Oficina de Computacin del Instituto,
se encuentran:
Soporte Tcnico: dar continuidad operativa a los equipos de los investigadores
y profesores as como a las distintas salas de proyectos y estudiantes, de igual
forma, debe mantenerse la operatividad de los componentes adicionales tales
como impresoras y plotters entre otros.

II

Introduccin

Soporte Logstico: realizar respaldos temporales y definitivos de los proyectos

de investigacin y extensin, as como de la informacin generada por las
actividades de docencia. Esto implica respaldar la data bruta almacenada en
los servidores, lo cual incluye la entregada a los clientes.
Administracin de Redes: supervisar, prevenir y tomar acciones correctivas
para los problemas con la plataforma de red del instituto. As mismo, planificar
el crecimiento y actualizacin de la misma.
Administracin de Servidores: mantener operativos los servidores (de archivo,
de impresin y de correo/web) de manera continua y planificar su actualizacin
y sustitucin. De igual forma planificar los mecanismos de respaldo y
recuperacin.
Soporte a Usuarios: prestar servicio de apoyo a los desarrollos tanto de
investigacin como de docencia y extensin brindando mximo respaldo al uso
de nuevas tecnologas, as como, prestar ayuda al nuevo personal para el uso
de stas.
Labores Administrativas: llevar control de los activos disponibles,
identificndolos de manera tal que sean diferenciados al momento de realizar
las funciones administrativas como plizas de seguro, desincorporaciones y
actualizaciones. Adems, la oficina lleva a cabo todas las solicitudes de
financiamiento para adquisicin de nuevos equipos y software, incluyendo la
plataforma de red.
Apoyo Interinstitucional: llevar a cabo convenios y dar apoyo a las otras
unidades tcnicas de la facultad en el desarrollo de proyectos conjuntos que
benefician al todo, representado por la Facultad de Arquitectura y Urbanismo.
Los problemas que se identifican ante estas funciones, son entre otros los
siguientes:

Falta de seguimiento a los requerimientos tcnicos de los usuarios.

Inventarios desactualizados. Tanto de equipos como de software

respaldado.

Falta de control en la previsin del mantenimiento de los equipos.

Falta de control en los procesos de desincorporacin.

Falta de control en el seguimiento (tanto de recaudos, como de cobros y

entregas de equipos) con los entes financiadores.
Es necesario, que todos estos controles en soporte, inventario y
administracin; se lleven de forma automatizada y no manual como hasta
ahora se ha hecho. Cuando los usuarios se dan cuenta que no tienen el control
de la situacin, que no pueden manejar estadsticas de eventos, que se les
dificulta llevar control de los inventarios y esto a su vez repercute en sus
labores administrativas; es el momento de pensar en una herramienta que los
ayude. Porque es necesario controlar y analizar las actividades realizadas; para
mejorar, simplificar y cuantificarlas. En este caso, se trabajar con la Oficina

III

Introduccin

de Computacin del Instituto de Urbanismo de la Facultad de Arquitectura de

la Universidad Central de Venezuela; mediante el diseo de un prototipo que
modele el flujo de trabajo asociado a dichas actividades.
En el Capitulo II del presente documento se plantea en detalle el problema que
vive el Instituto de Urbanismo de la Facultad de Arquitectura de la Universidad
Central de Venezuela. Se definen los objetivos y se justifica el desarrollo de
este trabajo.
En el Capitulo III se especifica la metodologa estudiada. Se habla del Proceso
Unificado, Metodologas de Diseo y de Workflow.
El Capitulo IV hace referencia al Diseo y Desarrollo. Qu se hizo para resolver
el problema planteado.
Luego, se presenta un Capitulo V con Conclusiones y Recomendaciones.
Referencias y Bibliografa.

IV

Planteamiento Del Problema

Capitulo II
Planteamiento Del Problema
Al realizar un estudio de los procesos actuales que se llevan a cabo en la
Oficina de Computacin, se encuentra que todo se realiza de forma manual. Al
analizar el desarrollo de los procesos se nota una carencia absoluta de
mecanismos automatizados o an falta de controles o documentacin de los
mismos, lo que hace imposible valorar el desempeo de los mismos de
ninguna manera. Por esto, es necesario disear un sistema automatizado, que
colabore con el personal de la Oficina de Computacin para los controles y
seguimiento de sus distintas funciones. Se debe construir un proceso por
medio del cual los clientes finales o usuarios puedan de manera interactiva
actualizar la informacin de las actividades que involucran insumos para los
procesos administrativos de la oficina, como son, nuevas investigaciones o
proyectos, aprobacin de tesis, entre otros. De los procesos actuales, se debe
probar la calidad de los mismos, la prestacin del servicio y las herramientas
que deben ser desarrolladas para cubrir las necesidades de la Oficina de
Computacin.
Visto esto, se evidencia la necesidad de desarrollar herramientas efectivas que
permitan el control y manejo de los distintos procesos notndose
principalmente la necesidad de un inventario de equipos que sea duradero,
estadsticas de atencin y una herramienta de manejo de insumos para los
procesos administrativos.
Por lo tanto y como norte de este trabajo, se debe realizar un prototipo que,
tomando las necesidades existentes y las soluciones planteadas, permita
simular los procesos realizados de manera tal que faciliten la documentacin,
evaluacin y apoyo a los mismos para as mejorar sustancialmente las
actividades relacionadas a la oficina.
Oficina de Computacin:
La oficina de computacin cubre las actividades informticas del Instituto de
Urbanismo diferenciadas en tres aspectos: 1) Tcnicos, que cubre las funciones
de soporte (a equipos y a usuarios), mantenimiento de estaciones de trabajo y
de servidores, control de usuarios (claves de acceso, direcciones de correo-e,
agenda). 2) Administrativos, el Inventario y Trnsito de Equipos (adquisiciones
y desincorporaciones) y 3) Presupuestarios, que cubre los aspectos asociados a
los trmites con CDCH, Postgrado, Facultad de Arquitectura y otros entes que
financian.
Pero como se ha hecho notar, la forma en que estos procedimientos son
llevados a cabo, generan ciertos problemas como son la falta de seguimiento a
los requerimientos tcnicos de los usuarios, inventarios desactualizados, falta
de control en la previsin de los mantenimientos de los equipos y de los

Planteamiento Del Problema

procesos de desincorporacin as como retardos con los entes financiadores, a

veces por la cantidad de informacin disponible y la variedad de los contactos.
Avanzando en el anlisis se encuentra el hecho notable que siendo la actividad
principal de la Oficina de Computacin el proceso de soporte no se mantiene
ningn registro de la misma. Por otro lado asegurar los equipos de
computacin es una de las obligaciones de la Oficina de Computacin, sin
embargo el no tener un inventario actualizado hace cuesta arriba esta labor.
Un estado ideal de la dependencia tratada sera poder controlar todas las
actividades de soporte, mantener un control total del inventario y mantener
registro de los insumos para los procesos administrativos.
Sin embargo, se es conciente que la utilizacin de ciertas herramientas nuevas
debe venir acompaada de un procedimiento que logre romper la resistencia al
cambio y que los usuarios se acostumbren a utilizar el sistema mientras se
crea la costumbre de uso del mismo.
Uno de los aspectos motivantes para la incorporacin de nuevas metodologas
y herramientas es el hecho que sea la Oficina de Computacin la que tenga la
carencia de un sistema que controle su gestin. Esta falta de controles se
evidencia por ejemplo cuando se van a hacer las solicitudes al CDCH. Cuando
corresponde la renovacin de Plizas de Seguros de la plataforma informtica.
Para el seguimiento de los casos y solicitudes de apoyo de los usuarios; entre
otros. Lo que lleva a hechos como que los usuarios hacen la misma solicitud en
repetidas oportunidades, se pierde el seguimiento de recaudos y de cobros y
entregas de equipos con los entes financiadores, as como se duplican
solicitudes de desincorporacin poniendo de manifiesto el descontrol de los
procesos.
Para resolver esta situacin se propone la creacin de las siguientes
herramientas: Un subsistema de control de requerimientos (en lnea y con
disponibilidad de estadsticas), un subsistema de inventario, un subsistema de
indicadores de eventos (de acuerdo a la fecha del ltimo mantenimiento,
indicar cuando debe realizarse el siguiente, ya sea por correo o por algn otro
medio), un subsistema de manejo de adquisiciones y desincorporaciones
(como parte del subsistema de inventario). Debe llevar el control de los
equipos desincorporados o por desincorporar, as como de aquellos que han
sido adquiridos y que an no estn inventariados, un subsistema de trmites
(un subsistema que permita llevar control de las solicitudes, nmeros, equipos
solicitados, fechas aproximadas, realizadas ante los entes financiadores de
equipos de la unidad de computacin). El presente trabajo plantea la creacin
de un prototipo que muestre las actividades realizadas y los procesos que
facilitaran el desarrollo y control de los mismos.

Planteamiento Del Problema

Objetivos Generales
Se plantea desarrollar una herramienta automatizada de Control de Gestin
para la Oficina de Computacin que permita llevar un control eficiente de las
actividades realizadas, para enfrentar la problemtica del control y seguimiento
de las mismas. A partir de este conocimiento, activar la sinergia de estos
recursos para dar respuestas adecuadas, oportunas y pertinentes a los
problemas tcnicos y administrativos de la dependencia.
Objetivos Especficos

Disear un subsistema de control de requerimientos (en lnea y con

disponibilidad de estadsticas).
Disear un subsistema de inventario.
Disear un subsistema de indicadores de eventos (de acuerdo a la fecha
del ltimo mantenimiento, indicar cuando debe realizarse el siguiente,
ya sea por correo o por algn otro medio).
Disear un subsistema de manejo de adquisiciones y desincorporaciones
(como parte del subsistema de inventario). Debe llevar el control de los
equipos desincorporados o por desincorporar, as como de aquellos que
han sido adquiridos y que an no estn inventariados.
Disear un subsistema de trmites (un subsistema que permita llevar
control de las solicitudes, nmeros, equipos solicitados, fechas
aproximadas, realizadas ante los entes financiadores de equipos de la
unidad de computacin).
Justificacin del Trabajo

El presente trabajo plantea la solucin de problemas existentes en una oficina

de computacin que presta servicios tcnicos y administrativos a un instituto
de investigacin de la Universidad Central de Venezuela, al realizar este
proyecto, se sentar un precedente que permitir desarrollar proyectos
similares en otras dependencias que permitir mejorar el funcionamiento de
las mismas, por otra parte, los aspectos administrativos de los institutos de
investigacin siempre han sido un tema de importancia prioritaria, pues estos
medios son los que permiten financiar el mantenimiento y crecimiento de las
actividades de investigacin.
Por otro lado, el control de las actividades de soporte permitir la produccin
de medidas estadsticas, que redundar en mtodos de evaluacin continua
para el personal de la oficina, as como en un medidor de las debilidades de los
usuarios para poder planificar actividades de mejoramiento en el rea de
computacin.

Planteamiento Del Problema

Pero la razn de mayor peso para el desarrollo de este proyecto es la creacin

de una memoria institucional, pues se realizar un mejor seguimiento de las
actividades relacionadas a la oficina de computacin de la institucin en la que
se aplique la herramienta.

Metodologa

Capitulo III
Metodologa
Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma
total de los programas de computadora, procedimientos, reglas, la
documentacin asociada y los datos que pertenecen a un sistema de cmputo".
Segn el mismo autor, "un producto de software es un producto diseado para
un usuario". En este contexto, la Ingeniera de Software (SE del ingls
Software Engineering) es un enfoque sistemtico del desarrollo, operacin,
mantenimiento y retiro del software", que en palabras ms llanas, se considera
que "la Ingeniera de Software es la rama de la ingeniera que aplica los
principios de la ciencia de la computacin y las matemticas para lograr
soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de
desarrollo de software", es decir, "permite elaborar consistentemente
productos correctos, utilizables y costo-efectivos" [Cota 1994].
El proceso de ingeniera de software se define como "un conjunto de
etapas parcialmente ordenadas con la intencin de lograr un objetivo, en este
caso, la obtencin de un producto de software de calidad" [Jacobson 1998].El
proceso de desarrollo de software "es aquel en que las necesidades del
usuario son traducidas en requerimientos de software, estos requerimientos
transformados en diseo y el diseo implementado en cdigo, el cdigo es
probado, documentado y certificado para su uso operativo". Concretamente
"define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto
objetivo" [Jacobson 1998].
El proceso de desarrollo de software requiere por un lado un conjunto de
conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le
llama el ciclo de vida del software que comprende cuatro grandes fases:
concepcin, elaboracin, construccin y transicin. La concepcin define el
alcance del proyecto y desarrolla un caso de negocio. La elaboracin define un
plan del proyecto, especifica las caractersticas y fundamenta la arquitectura.
La construccin crea el producto y la transicin transfiere el producto a los
usuarios.
Actualmente se encuentra en una etapa de madurez el enfoque Orientado a
Objetos (OO) como paradigma del desarrollo de sistemas de informacin. El
Object Management Group (OMG) es un consorcio a nivel internacional que
integra a los principales representantes de la industria de la tecnologa de
informacin OO. El OMG tiene como objetivo central la promocin,
fortalecimiento e impulso de la industria OO. El OMG propone y adopta por
consenso especificaciones entorno a la tecnologa OO. Una de las
especificaciones ms importantes es la adopcin en 1998 del Lenguaje de
Modelado Unificado o UML (del ingls Unified Modeling Language) como un
estndar, que junto con el Proceso Unificado estn consolidando la tecnologa
OO.

Metodologa

El Proceso Unificado
El Proceso Unificado "es un proceso de desarrollo de software configurable
que se adapta a travs de los proyectos variados en tamaos y complejidad.
Se basa en muchos aos de experiencia en el uso de la tecnologa orientada a
objetos en el desarrollo de software de misin crtica en una variedad de
industrias por la compaa Rational", donde confluyen 'los tres amigos' como
se llaman a s mismos o los tres grandes OO: Grady Booch, James Rumbaugh
e Ivar Jacobson [M&R 1998].
El Proceso Unificado gua a los equipos de proyecto en cmo administrar el
desarrollo iterativo de un modo controlado mientras se balancean los
requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El
proceso describe los diversos pasos involucrados en la captura de los
requerimientos y en el establecimiento de una gua arquitectnica lo ms
pronto, para disear y probar el sistema hecho de acuerdo a los
requerimientos y a la arquitectura. El proceso describe qu entregables
producir, cmo desarrollarlos y tambin provee patrones. El proceso unificado
es soportado por herramientas que automatizan entre otras cosas, el modelado
visual, la administracin de cambios y las pruebas.
Proceso Unificado y MSF; Complementos Tecnolgicos
Segn [M&R 1998], "ms que una metodologa, Microsoft Solutions Framework
(MSF) es una serie de modelos flexibles interrelacionados que guan a una
organizacin sobre como ensamblar los recursos, el personal y las tcnicas
necesarias para asegurar que su infraestructura tecnolgica y sus soluciones
cumplan los objetivos de negocio. MSF mantiene una relacin clara entre los
objetivos de negocio y las implementaciones tecnolgicas".
"MSF se puede utilizar por s mismo o con otras herramientas y tcnicas como
el Proceso Rational [Proceso Unificado] para planear, construir y administrar el
desarrollo de soluciones de negocio a la medida" [M&R 1998].
"El Proceso Unificado es un proceso de desarrollo de software configurable que
se adapta a proyectos que varan en tamao y complejidad. Se basa en
muchos aos de experiencia en el uso de la tecnologa de objetos en el
desarrollo de software de misin crtica en una variedad de industrias. Uno de
los componentes clave es el UML" [M&R 1998].
MSF proporciona las tcnicas ligadas a la tecnologa y el Proceso Unificado la
gua detallada para el desarrollo de software minimizando los riesgos.
El Proceso Unificado ha adoptado un enfoque que se caracteriza por:

Interaccin con el usuario continua desde un inicio

Atenuacin de riesgos antes de que ocurran
Liberaciones frecuentes
9

Metodologa

Aseguramiento de la calidad
Involucrar al equipo en todas las decisiones del proyecto
Anticiparse al cambio de requerimientos

El Proceso Unificado y MSF se enfocan en la arquitectura como el centro del

desarrollo para asegurar que el desarrollo basado en componentes sea clave
para un alto nivel de reutilizacin. MSF considera que hay cuatro perspectivas
de arquitectura que cumplen los requerimientos de una empresa [M&R
1998]:

Arquitectura de Negocios: Describe como opera un negocio.

Desarrolla una imagen clara de los procesos de flujo de trabajo de la
organizacin y de cmo son apoyados por una infraestructura
tecnolgica basada en servicios.
Arquitectura de Aplicacin: Adopta un modelo de aplicacin de toda
la empresa para disear y desarrollar sistemas de negocios que puedan
compartir un conjunto de componentes back-end de alto valor.
Arquitectura de Informacin: Define qu informacin es necesaria
para apoyar el proceso de negocios y como poner esa informacin
eficientemente en manos de quienes que la necesitan sin crear islas de
datos inaccesibles ni sistemas redundantes.
Arquitectura Tecnolgica: Define los estndares y guas para la
adquisicin y despliegue de herramientas, bloques de construccin de
aplicaciones, servicios de infraestructura, componentes de conectividad
de red y plataformas cliente servidor.

El Modelo de Equipo de MSF muestra como estructurar equipos de alto

desempeo para crear soluciones ms rpido, mejor y ms baratas. El Modelo
de Equipo de MSF se basa en las formas de organizar equipos para crear los
propios productos de Microsoft. Hace nfasis en las comunicaciones claras y en
un equipo de iguales con papeles y responsabilidades claras en todo el
proyecto. La calidad del producto se asegura por cada miembro del equipo. El
Proceso Unificado proporciona ms detalle y gua para algunos de los roles en
el proyecto.
Una vista arquitectnica es "una descripcin simplificada (una abstraccin)
de un sistema desde una perspectiva particular o punto de vista, que cubre
particularidades y omite entidades que no son relevantes a esta perspectiva"
[Booch 1998].
Segn Booch, las caractersticas primordiales del Proceso Unificado son:

Iterativo e incremental
Centrado en la arquitectura
Guiado por casos de uso
Confrontacin de riesgos

10

Metodologa

El Proceso Unificado es un proceso porque "define quin est haciendo qu,

cundo hacerlo y cmo alcanzar cierto objetivo, en este caso el desarrollo de
software" [Jacobson 1998]. Segn [Booch 1998], los conceptos clave del
Proceso Unificado son:
Fase e iteraciones

Cundo se hace?

Flujos de trabajo de procesos (actividades y pasos)

Qu se est haciendo?

Artefactos (modelos, reportes, documentos)

Qu se produjo?

Trabajador: un arquitecto

Quin lo hace?

El ciclo de vida del software en el Proceso Unificado

Las fases del ciclo de vida del software son: concepcin, elaboracin,
construccin y transicin. La concepcin es definir el alcance del proyecto y
definir el caso de uso. La elaboracin es proyectar un plan, definir las
caractersticas y cimentar la arquitectura. La construccin es crear el producto
y la transicin es transferir el producto a sus usuarios [Booch 1998].

Figura 1. Estructura del Proceso Unificado

Segn [Microsoft 1997], el diseo de software se realiza a tres niveles:

conceptual, lgico y fsico.

11

Metodologa

Figura 2. Arquitectura lgica de tres capas de una aplicacin cliente/servidor

Diseo Conceptual
El diseo conceptual se considera como un anlisis de actividades y consiste
en la solucin de negocios para el usuario y se expresa con los casos de uso. El
diseo lgico es la solucin del equipo de proyecto del negocio y consiste de
las siguientes tareas:

Identificar los usuarios y sus roles

Obtener datos de los usuarios
Evaluar la informacin
Documentar los escenarios de uso
Validar con los usuarios
Validar contra la arquitectura de la empresa

Una forma de obtener estos requerimientos es construir una matriz usuariosactividades de negocios, realizar entrevistas, encuestas y/o visitas a los
usuarios, de tal manera que se obtenga quin, qu, cundo, dnde y por qu
de la solucin.
Diseo Lgico
El diseo lgico traduce los escenarios de uso creados en el diseo
conceptual en un conjunto de objetos de negocio y sus servicios. El diseo
lgico se convierte en parte en la especificacin funcional que se usa en el
diseo fsico. El diseo lgico es independiente de la tecnologa. El diseo
lgico refina, organiza y detalla la solucin de negocios y define formalmente
las reglas y polticas especficas de negocios.

12

Metodologa

Un objeto de negocios es la encapsulacin de un servicio que abstrae las

cualidades esenciales de algo de inters.
Un servicio es una unidad con capacidad de cmputo. Un servicio debe
satisfacer lo siguiente:

Ser seguro, lo que equivale a un uso correcto y con autorizacin

Ser vlido, qu tareas o reglas se pueden aplicar
Manejar excepciones, informando al cliente
Contar con un catlogo de servicios que constituye un repositorio de
servicios.

Los objetos de negocio deben verificarse y probarse de tal manera que asegure
que los mdulos operen como unidades completas de trabajo. Las tareas de
verificacin incluyen:

Una verificacin independiente:

o Pre y post condiciones
o Lgica y funcionalidad individual
Una verificacin dependiente:
o Verificacin de dependencias
o Que operan como una unidad especfica de trabajo

El diseo lgico comprende las siguientes tareas:

Identificar y definir los objetos de negocio y sus servicios

Definir las interfases
Identificar las dependencias entre objetos
Validar contra los escenarios de uso
Comparar con la arquitectura de la empresa
Revisar y refinar tanto como sea necesario

Para definir los objetos de negocios y sus servicios se puede usar la tcnica de
anlisis nombre-verbo de los escenarios de uso. Tambin se puede emplear la
tcnica sujeto-verbo-objeto directo. En estas tcnicas los sujetos y el objeto
directo son los candidatos a objetos de negocio y los verbos activos son los
candidatos a servicios.
Una interface tiene las siguientes partes:

Nombre
Precondiciones, lo que debe estar presente antes de ejecutarse
Postcondiciones, estado final
Capacidad o funcionalidad (SQL, pseudocdigo, funcin matemtica)
Dependencias

La tarea de identificar las dependencias entre objetos permite identificar

eventos, sucesos o condiciones que permitan la realizacin de tareas de
13

Metodologa

negocios coordinadamente o transaccionalmente. Para ello se debe considerar

lo siguiente:

Identificar los eventos disparadores (triggers)

Determinar cualquier dependencia (existencial o funcional)
Determinar cualquier problema de consistencia o secuencia
Identificar cualquier regulacin de tiempo crtica
Considerar algn problema organizacional (transacciones)
Identificar y auditar los requerimientos de control
Determinar lugares y dependencias a travs de la ubicacin
Determinar cuando el servicio que controla la transaccin
dependiente de los servicios contenidos en otros objetos de negocio

es

La validacin del modelo lgico debe ser tal que ste sea:

Completo debe representar todos los escenarios de uso,

Correcto el comportamiento lgico debe corresponder con
comportamiento conceptual, y
Claro los objetos de negocio y servicios no deben ser ambiguos

el

En el diseo lgico conceptualmente se divide en tres niveles de servicios con

el fin de que la aplicacin resulte flexible ante los cambios de requerimientos
y/o de tecnologa cambiando nicamente la capa o capas necesarias. Los tres
niveles son: servicios de usuario, servicios de negocio y servicios de datos.
Los servicios de usuario (user services) controlan la interaccin. Un servicio
de usuario son personas, aplicaciones, otros servicios o la combinacin de
stos. Generalmente involucra una interfase grfica de usuario (GUI) o pude
ser no visual (mensajes o funciones), maneja todos los aspectos de la
interaccin con la aplicacin. El objetivo central es minimizar el esfuerzo de
conocimiento requerido para interpretar la informacin. Un servicio de usuario
incluye un contenido (qu se necesita comunicar al usuario) y una forma
(cmo se comunica el contenido) cuando es necesaria la comunicacin.
Los servicios de negocio (bussines services) convierten datos recibidos de
los servicios de datos y de usuario en informacin (datos + regla de negocio) y
pueden usar otros servicios de negocio para completar su tarea.
Las tareas de los servicios de negocio son:

Dar formato a los datos

Obtener y mover datos desde y hasta los servicios de datos
Transformar los datos en informacin
Validar los datos inmediatamente en el contexto o en forma diferida una
vez terminada la transaccin.

14

Metodologa

Los servicios de datos (data services) son los servicios de bajo nivel que
apoyan los servicios de negocio y son de una amplia gama de categoras como
las siguientes:

Declaracin del esquema y su evolucin (estructuras de datos, tipos,

acceso indexado, SQL, APIs)
Respaldo y recuperacin (recuperacin de datos si un evento falla)
Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin
de solicitudes, formacin de un conjunto de resultados)
Insercin,
actualizacin
y
borrado
(procesar
modificaciones
consistentemente transaccional). Una transaccin es atmica (ocurre o
no), consistente (preserva integridad), aislada (otras transacciones
ocurren antes o despus) y durable (una vez completada, sta
sobrevive).
Bloqueo (permite al acceso concurrente a los datos)
Validacin de datos (verifica la integridad del dominio, triggers y
gateways para verificar el estado de los datos antes de aceptarlos,
manejo de errores)
Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario
y grupos y servicios)
Administracin de la conexin (mecanismos bsicos para establecer una
sesin de los servicios de datos). Establecer una conexin involucra: una
identificacin, la colocacin y provisin de datos, tiempo de sesin, el
tipo de interaccin (conversacional, transaccional, multiusuario,
monousuario).
Distribucin de datos (Distribuye informacin, a mltiples unidades de
recuperacin, bases de datos heterogneas, segn la topologas de la
red).
Diseo Fsico

El diseo fsico traduce el diseo lgico en una solucin implementable y

costo-efectiva o econmica.
El componente es la unidad de construccin elemental del diseo fsico. Las
caractersticas de un componente son:

Se define segn cmo interacta con otros

Encapsula sus funciones y sus datos
Es reusable a travs de las aplicaciones
Puede verse como una caja negra
Puede contener otros componentes

En el diseo fsico se debe cuidar el nivel de granularidad (un componente

puede ser tan grande o tan pequeo segn su funcionalidad, es decir, del
tamao tal que pueda proveer de una funcionalidad compleja pero de control
genrico) y la agregacin y contencin (un componente puede reusar
utilizando tcnicas de agregacin y contencin, sin duplicar cdigo).
15

Metodologa

El diseo fsico debe involucrar:

El diseo para distribucin debe minimizarse la cantidad de datos que

pasan como parmetros entre los componentes y stos deben enviarse
de manera segura por la red.
El diseo para multitarea debe disearse en trminos de la
administracin concurrente de dos o ms tareas distintas por una
computadora y el multithreading o mltiples hilos de un mismo proceso)
El diseo para uso concurrente el desempeo de un componente
remoto depende de si est corriendo mientras recibe una solicitud.
El diseo con el manejo de errores y prueba de eventos:
o Validando los parmetros- a la entrada antes de continuar con
cualquier proceso.
o Protegiendo recursos crticos manejar excepciones para evitar la
falla o terminacin sin cerrar archivos, liberar objetos
sincronizados o memoria.
o Protegiendo datos importantes contar con una excepcin a la
mitad de la actuacin en las bases de datos.
o Debugging crear una versin para limpiar errores.
o Proteccin integral de transacciones de negocios los errores
deben regresarse al componente que llama.

Figura 3. Arquitectura fsica de tres capas de la aplicacin cliente/servidor

16

Metodologa

El diseo fsico comprende las siguientes tareas:

Definir los componentes

Refinar el empaquetamiento y distribucin de componentes
Especificar las interfases de los componentes
Distribuir los componentes en la red
Distribuir los repositorios fsicos de datos
Examinar la tolerancia a fallas y la recuperacin de errores
Validar el diseo fsico

De las tareas anteriores la ms importante es la distribucin de los datos que

pueden ser centralizados, una particin, un extracto o una rplica.
Los datos centralizados equivalen a una base de datos maestra ubicada en
un lugar central. No hay copias de los datos.
Una particin de datos es una segmentacin de la base de datos maestra. Es
til cuando los datos se pueden fragmentar fcilmente y actualizarse en un
sitio local con cambios frecuentes. No hay sobreposicin entre particiones. En
una particin horizontal cada hilera existe en una sola base de datos. En una
particin vertical cada columna es contenida en una y solo una base de datos.
Un extracto de datos es una copia de toda o una porcin de la base de datos
maestra. No se permite la actualizacin. Se usa un timestamp o etiqueta de
tiempo para indicar qu tan viejos son los datos.
Una rplica de datos es un fragmento de la bases de datos maestra que se
puede actualizar. Una rplica de datos es cuando el sitio de actualizacin
cambia a un sitio local. No se permiten actualizaciones en la base de datos
rplica y en la base de datos maestra a la vez, por lo que debe de haber
sincronizacin entre ambas.
El diseo fsico est ntimamente ligado a una alternativa tecnolgica. Ante la
acelerada evolucin tecnolgica es importante considerar los estndares del
momento y las tendencias ya que una mala decisin implicar un costo enorme
(en dinero y en tiempo) al actualizarse a otra plataforma distinta.
La tendencia actual en la arquitectura cliente/servidor es crear el back-end
como un servidor robusto multitareas y multithreading y el front-end como un
cliente muy delgado que no acapare al servidor comunicndose entre s en una
plataforma internet con protocolos estndar en redes heterogneas.
Workflow
Los Workflows son sistemas que ayudan a administrar y automatizar procesos
de negocios. Un Workflow puede ser descrito como el flujo y control en un
proceso de negocio. La WfMC (Workflow Management Coalition) define a los
workflows como [1]:
17

Metodologa

"La automatizacin de un proceso de negocio, total o parcial, en la cual

documentos, informacin o tareas son pasadas de un participante a otro para
efectos de su procesamiento, de acuerdo a un conjunto de reglas
establecidas."
Tambin definen lo que es un proceso de negocio:
"Es un conjunto de uno o mas procedimientos o actividades directamente
ligadas, que colectivamente realizan un objetivo del negocio, normalmente
dentro del contexto de una estructura organizacional que define roles
funcionales y relaciones entre los mismos."
Entre los ejemplos de proceso de negocios se tiene: procesamiento de
rdenes, reportes de gastos, procedimientos de produccin, etc.
Cabe mencionar que los workflows son solo un camino para la informacin,
para reducir tiempo, dinero y esfuerzo en la ejecucin de un proceso de
negocio. Las funciones ms comunes que proporcionan los workflows son:

Asignacin de tareas al personal.

Aviso al personal de tareas pendientes.
Aviso al personal de tareas pendientes.
Permitir la colaboracin en las tareas comunes.
Optimizacin de recursos humanos y tcnicos, alinendolos a la
estrategia de la empresa.
Automatizacin de las secuencias de los procesos de negocio y
optimizacin de las mismas.
Agilizacin de los procesos de negocio y como resultado un mejor
servicio al cliente.
Control y seguimiento de dichos procesos.

Como se mencion anteriormente, un workflow es el control del flujo de

informacin en un proceso de negocio. Para poder identificar cada elemento
dentro de cada workflow se puede utilizar el modelo de componentes de
proceso de negocio (BPCM, Bussines Process Component Model).
En la figura 4, se puede observar los elementos que forman a un proceso.

18

Metodologa

Figura 4. Elementos clave de un proceso de negocio

Estos cuatro elementos clave forman parte de los componentes de un proceso

de negocios y por lo tanto de un workflow. Para identificar estos componentes
clave dentro de un proceso es necesario formularse las siguientes preguntas:
Qu rutas se siguen?, Qu gente participa?, Cul es el rol que juega cada
participante?, Qu decisiones son tomadas?, Cmo se llevan a cabo estas
decisiones?, Qu informacin es requerida por cada participante?. Estas
preguntas son indispensables para poder identificar correctamente los procesos
de negocio que pueden ser mejorados e implementados a travs de un
workflow.
A continuacin hablaremos brevemente del modelo de referencia de workflow.
El modelo de referencia de workflow mostrado en la figura 5 fue desarrollado
por la WfMC para tener una estructura genrica en el desarrollo de aplicaciones
de workflows, es decir, un estndar.

19

Metodologa

Figura 5. Modelo de referencia de Workflow- componentes e interfaces

El modelo de referencia de Workflow fue desarrollado a partir de estructuras

genricas de aplicaciones de Workflow, identificando las interfaces con estas
estructuras, de forma que permita a los productos comunicarse a distintos
niveles. Todos los sistemas de Workflow contienen componentes genricos que
interactan de forma definida. Para poder tener cierto nivel de
interoperabilidad entre los diversos productos de Workflow, es necesario definir
un conjunto de interfaces y formatos para el intercambio de datos entre dichos
componentes. A continuacin se describen cada uno de los componentes e
interfaces que conforman este modelo.
Motor de Workflow (Workflow Engine)
El motor de workflow es el software que provee el control del ambiente de
ejecucin de una instancia de workflow. Tpicamente el motor provee
facilidades para: Interpretacin de la definicin de procesos; Control de las
instancias de los procesos: creacin, activacin, terminacin, etc.; Navegacin
entre actividades; Soporte de interaccin con el usuario; Control de datos al
usuario o hacia aplicaciones; Invocacin de aplicaciones externas; Servicio de
Representacin de Workflow (Workflow Enactment Service)
Este componente interpreta la descripcin de procesos y controla las diferentes
instancias de los procesos, secuencia de actividades, adiciona elementos a la
lista de trabajo de los usuarios, e invoca aplicaciones necesarias. Todas estas
tareas son hechas por uno o ms motores de Workflow, los cuales manejan la
ejecucin de las distintas instancias de varios procesos. La lista de trabajo
forma parte de los datos del Workflow, ya que la interaccin con los usuarios
es necesaria en algunos casos, el motor de Workflow utiliza una lista de
trabajo manipulada por un manejador de lista de trabajo para controlar tal
interaccin. El motor deposita en la lista de trabajo los elementos a ser
20

Metodologa

ejecutados por cada usuario. La lista de trabajo puede ser visible o invisible
para los usuarios dependiendo del caso, muchas veces se deja que el usuario
seleccione elementos y los procese en forma individual.
Interfaz de Programacin de Aplicaciones de Workflow (WAPI)
Las WAPI pueden ser vistas como un conjunto de APIs (Application
Programming Interface) y funciones de intercambio soportadas por el servicio
de representacin de workflow. Las WAPI permiten la interaccin del servicio
de representacin de workflow con otros recursos y aplicaciones.
Herramientas de definicin de procesos (Interfaz 1)
Existe una gran variedad de herramientas utilizadas para el anlisis de
procesos. Estas herramientas pueden variar desde las ms informales hasta las
ms formales y sofisticadas. La salida de este proceso de modelado y diseo es
una definicin de procesos la cual puede ser interpretada en tiempo de
ejecucin por el o los motores de Workflow.
Aplicaciones clientes (interfaz 2)
En el modelo planteado la interaccin entre las aplicaciones clientes y el motor
de Workflow est sostenido en gran parte por el concepto de lista de trabajo ya
descrito anteriormente. Parte de la informacin almacenada en la lista de
trabajo es utilizada para trasmitirle al manejador de la lista de trabajo que
aplicaciones hay que invocar. La interfaz entre una aplicacin cliente de
Workflow y el motor de Workflow debe ser lo suficientemente flexible en los
siguientes puntos: identificadores de procesos y actividades, estructuras de
datos, diferentes alternativas de comunicacin.
Aplicaciones Invocadas (interfaz 3)
Esta interfaz est orientada a interactuar con agentes de una aplicacin, o con
toda la aplicacin. Dichas aplicaciones deben estar orientadas al contexto
general de un sistema de Workflow, es decir, deben poder interactuar
directamente con el motor de Workflow. La aplicacin invocada es manejada
localmente por un motor de Workflow, usando la informacin suministrada en
la definicin del proceso para identificar la naturaleza de la actividad. La
aplicacin invocada puede ser local al motor de Workflow, es decir, residente
en la misma plataforma, o estar en otra plataforma dentro de una red. En este
caso la definicin del proceso debe contener informacin necesaria para poder
encontrar la aplicacin que se va a invocar (por ejemplo la direccin dentro de
la red).
Funciones de Interoperabilidad WAPI (interfaz 4)
Existen dos aspectos necesarios para la interoperabilidad:

21

Metodologa

Alcance de la interpretacin comn de la definicin de procesos que ser

realizada.
Soporte en tiempo de ejecucin para el intercambio de diferentes tipos de
informacin de control y transferencia de los datos relevantes del Workflow,
y/o de las aplicaciones entre los distintos servicios de representacin.
Herramientas de administracin y monitoreo (interfaz 5)
El propsito de esta interfaz es permitir una vista completa del estado del flujo
de trabajo, adems de poder realizar auditorias sobre los datos del sistema.
Ya que se sabe como esta construido el modelo de referencia de un workflow,
veamos ahora una de sus clasificaciones.
Clasificacin de los diferentes tipos de Workflow
Debido a la diversidad de procesos de negocio que existen dentro de las
empresas, se tiene la siguiente clasificacin para los workflows: de produccin,
de colaboracin y de administracin.
a) Workflow de Produccin
Frecuentemente este tipo de Workflow es llamado Workflow de Transacciones.
Esto se debe a que la transaccin en una base de datos es considerada la clave
de todo proceso. Este tipo de Workflow es el segmento ms grande en el
mercado. En general automatizan procesos de negocios que tienden a ser
repetitivos, bien estructurados y con gran manejo de datos.
b) Workflow de Colaboracin
Las aplicaciones de Workflow que resuelven procesos de negocios donde
participa gente para lograr una meta comn, son llamadas Workflow de
Colaboracin. Los Workflow de colaboracin estructuran o semiestructuran
procesos de negocios donde participan personas, con el objetivo de lograr una
meta comn.
Tpicamente involucran documentos, los cuales son los contenedores de la
informacin. Se sigue la ruta de estos paso a paso, adems de las acciones
que se toman sobre ellos. Los documentos son la clave, y por lo tanto es
esencial para la solucin de Workflow mantener la integridad de dichos
documentos.
c) Workflow de Administracin
El Workflow Administrativo como lo dice su nombre es aquel que involucra
procesos de administracin en una empresa tales como rdenes de compra,
reportes de ventas, etc. Estos workflows se emplean cuando existe una gran
22

Metodologa

cantidad de procesos administrativos dentro de la empresa y es necesaria la

distribucin de soluciones a diferentes usuarios. Una solucin de Workflow
Administrativo difiere para cada organizacin, y los cambios son frecuentes.
Por esto, la posibilidad de poder hacer cambios de diseo es muy importante.
Veamos ahora las ventajas que brinda la utilizacin de la tecnologa de
workflow dentro de una empresa.
Ventajas de los workflows
La automatizacin de los procesos de negocio de una empresa trae grandes
beneficios como la reduccin del tiempo de bsqueda de papeles o el menor
gasto en papelera, estos problemas son los primeros que se atacaron con la
tecnologa de workflows. A continuacin conoceremos algunas razones por las
cuales las organizaciones podran considerar adoptar una solucin de workflow.
Eficiencia en los procesos y estandarizacin de los mismos. Esto conduce a:
Una reduccin de costos dentro de una empresa.
La estandarizacin de los procesos lleva a tener un mayor conocimiento de los
mismos, lo que a su vez conduce a obtener una mejor calidad de estos.
Administracin de los Procesos. Utilizando la tecnologa de Workflow es posible
monitorear el estado actual de las tareas as como tambin observar como
evolucionan los planes de trabajo realizados. Permite ver cuales son los
embotellamientos dentro del sistema, es decir aquellas tareas o decisiones que
estn requiriendo de tiempo no planificado y se tornan en tareas o decisiones
crticas.
Asignacin de tareas a la gente. La asignacin de tareas se realiza mediante la
definicin de roles dentro de la empresa, eliminando la tediosa tarea de
asignar los trabajos caso por caso.
Recursos disponibles. Se asegura que los recursos de informacin (aplicaciones
y datos) van a estar disponibles para los trabajadores cuando ellos los
requieran.
Diseo de procesos. Se fomenta a pensar los procesos de una manera distinta
a la tradicional forma jerrquica que se utiliza para disearlos en la actualidad.
Hay adems muchos aspectos operacionales por los cuales es deseable contar
con una tecnologa de Workflow ya que aspectos como la secuencia de tareas,
quienes realizan dicha secuencia, los mecanismos de control y monitoreo, son
implementadas en el software de Workflow.
El Workflow permite automatizar diferentes aspectos del flujo de la
informacin: rutear los trabajos en la secuencia correcta, proveer acceso a
datos y documentos, y manejar ciertos aspectos de la ejecucin de un proceso.

23

Metodologa

La diversidad de procesos que puede haber en una organizacin nos lleva a

pensar en la existencia de diferentes tipos de software de Workflow. El
Workflow entonces, ofrece a una empresa la posibilidad de automatizar sus
procesos, reducir costos, y mejorar servicios. Parece ser obvio que son grandes
beneficios. Organizaciones que no hayan evaluado esta tecnologa podran
encontrarse con desventajas en un futuro.
Workflow como herramienta de Reingeniera
Qu potencialidad tiene la reingeniera del negocio si adems se utiliza
Workflow?
La respuesta a esta interrogante es inmediata si conocemos algunos principios
que la Reingeniera propone:

Combinacin de tareas desarrollndose en el momento adecuado y

donde tienen ms sentido.
Reduccin de tiempos, verificaciones y controles.
Disminucin de niveles jerrquicos. Esto lleva a la ejecucin de los
procesos en el orden natural.
Las tareas se conviertan en procesos.

Por su parte, el Workflow nos ofrece:

Integracin entre personas, actividades, programas y datos.

Optimizacin de recursos humanos y tcnicos, alinendolos con la
estrategia del negocio.
Eliminacin de partes innecesarias en la secuencia de los procesos y la
automatizacin de dicha secuencia.

Se podran seguir enumerando elementos, pero la idea es simplemente

mostrar que el Workflow es estratgico en cualquier proceso de reingeniera.
Diversos autores, entre ellos, BID (1979), Montaner (1967), Jesualdo (1968),
Nerici (1971), Ilpes (1982), Segovia de T. (1993), Segovia (1995), Cerda
Gutirrez (1997), Arias (1998), Pea (2001), Feliu y Rios (2002), han
estudiado la metodologa de los proyectos en diferentes mbitos. Como
resultado de esta tarea existe un panorama histrico que refleja bsicamente
concepciones, modelos y estructuras.
El trmino proyecto es bsicamente polismico dado que se le relacionan
diferentes usos y aplicaciones. Esta diversidad de significados lo convierte en
un trmino impreciso.
Etimolgicamente, el vocablo proyecto proviene del latn proiectum, el cual
se compone del prefijo pro, que significa hacia delante e iectum que tiene
el alcance de lanzar. As, se podra entender como lanzar hacia delante. Esta

24

Metodologa

acepcin se refiere a uno de los significados que tiene la palabra: una idea de
alcanzar un objetivo especfico (Cerda Gutirrez, 1997).
En muchas reas del conocimiento existe coincidencia en que el trmino
proyecto se relaciona con un medio para alcanzar un fin determinado a nivel
operativo.
Filosficamente, al hablar del proyecto se hace referencia a una proyeccin
espiritual o social del ser humano. Para socilogos y antroplogos, el proyecto
significa un medio para transformar una comunidad. Es decir, el proyecto
puede ser una actitud o una realizacin. As, Arias (1998) define el proyecto
como un conjunto de ideas organizadas que pretenden alcanzar un objetivo,
para lo cual se realiza una serie de actividades en forma planificada.
La administracin de proyectos, de acuerdo con el modelo racional, es el
resultado del anlisis mediante la estrategia del sistema cerrado que tiene
como meta una red monoltica de control. La racionalidad tcnica ejecuta una
metodologa en secuencia con dependencia en cadena, es decir, la actividad Y
slo podr realizarse luego de haberse completado la X, y as sucesivamente
(Ilpes, 1982).
Desde el punto de vista del enfoque sistmico, el modelo de administracin de
proyectos proviene de la estrategia de sistemas abiertos, cuyo nfasis maneja
el objetivo que tiene como meta, incorpora la incertidumbre y reconoce la
interdependencia entre el proyecto y su medio. As, el proyecto, desde el punto
de vista sistmico, significa proponer la produccin de un bien o la prestacin
de un servicio con el empleo de una determinada tcnica, con la influencia del
medio ambiente (organizacin), a fin de obtener cierto resultado (salida). Esta
tcnica presupone la indicacin de los medios y recursos (entradas) necesarios
para su realizacin (proceso) y la adecuacin de los medios (a travs de la
retroalimentacin) a los resultados o productos que han de lograrse (Figura 6)
(BID, 1979).

25

Metodologa

Organizacin
(Medio Ambiente)

Insumos
(Recursos)

Actividades
Programadas
(Proceso)

Salidas
(Producto)

Adecuacin (criterios)
Del uso de recursos
(retroalimentacin)

Figura 6. Representacin del proyecto factible en el mtodo sistmico

Al considerar a la organizacin como un sistema, se hace necesario tomar en

cuenta el entorno que la rodea dado que provee los insumos o entradas de
recursos humanos, materiales, financieros y tcnicos para posibilitar los bienes
o servicios; de all la importancia de prever a travs de modelos, el
comportamiento del entorno inmediato y general que rodea a la organizacin.
Igualmente, la organizacin debe poseer medios de informacin que le
permitan captar y adecuar sus procesos a cualquier cambio del entorno que
pueda influir, por ejemplo: cambios polticos, econmicos, sociales,
tecnolgicos, etc.
A travs del anlisis de sistemas se obtiene una visin de la interaccin del
sistema con su medio ambiente a travs de la retroalimentacin. Bajo este
enfoque, Pea (2001) considera la gestin de proyectos como el proceso por el
cual se planifica, dirige y controla el desarrollo de un sistema aceptable con un
costo mnimo y dentro de un periodo de tiempo especfico. Tambin, Feliu y
Rios (2002) aplican el anlisis de sistemas al desarrollo de un Sistema de
Informacin, proceso que realizan en tres etapas: a) el anlisis de sistemas, b)
diseo de sistemas y c) la implantacin de sistemas.
En muchas oportunidades, el trmino proyecto se confunde con otros que
aparentan ser sinnimos, pero que en la prctica tienen mbitos muy
diferentes. Tal es el caso de las expresiones plan y programa. Para Stoner,
Freeman y Gilbert (2000) el plan hace referencia a un amplio conjunto de
fines, objetivos, estrategias, recursos, etc. para lograr el desarrollo de un
sector amplio (plan de desarrollo econmico de un pas o comunidad, plan de
estudios). El programa es un conjunto de proyectos, con metas y objetivos de
un plan que deben cumplirse en un tiempo determinado bajo la
responsabilidad de una unidad u organizacin especfica e independiente de los
programas. De esta manera existen diversas clases de proyectos: proyecto de
desarrollo, proyecto de gobierno, proyecto de inversin social, proyecto de
26

Metodologa

investigacin, proyecto de aprendizaje, proyecto de plantel, proyecto de aula,

proyecto factible.
Operativamente en planificacin, el proyecto se refiere a un conjunto de
elementos, etapas y recursos interrelacionados que se disean para resolver
problemas especficos. Por su parte, la metodologa de la investigacin,
considera un proyecto como una propuesta viable de estudio o investigacin
con mtodos y tcnicas definidas.
Diversos autores han definido el significado de un proyecto de investigacin.
As, Sabino (1994), un proyecto de investigacin es un plan definido y concreto
de una investigacin a realizar, con la especificacin de sus caractersticas
bsicas. Sierra Bravo (1991) seala que el proyecto de investigacin es la
organizacin temporal y econmica especfica de todas las fases y operaciones
de un proceso concreto de investigacin. En lneas generales, el proyecto de
investigacin es una descripcin concreta del estudio que se propone realizar
un investigador, donde expresa lo que va a desarrollar (objetivos) y como lo
har (metodologa). Es decir, la finalidad del proyecto de investigacin es
responder a interrogantes de investigacin mediante la bsqueda de nuevos
conocimientos.
Por otra parte, un proyecto factible, como su nombre lo indica, tiene un
propsito de utilizacin inmediata: la ejecucin de la propuesta.
En este sentido, la UPEL (1998) define el proyecto factible como un estudio
que consiste en la investigacin, elaboracin y desarrollo de una propuesta de
un modelo operativo viable para solucionar problemas, requerimientos o
necesidades de organizaciones o grupos sociales (p.7). la propuesta que lo
define puede referirse a la formulacin de polticas, programas tecnologas,
mtodos o procesos, que slo tienen sentido en el mbito de sus necesidades.
De igual manera, la Universidad Simn Rodrguez (1980) considera que un
proyecto factible consiste en un conjunto de actividades vinculadas entre s,
cuya ejecucin permitir el logro de objetivos previamente definidos en
atencin a las necesidades que pueda tener una institucin o un grupo social
en un momento determinado. Es decir, la finalidad del proyecto factible radica
en el diseo de una propuesta de accin dirigida a resolver un problema o
necesidad previamente detectada en el medio.
En cuanto a la realizacin de trabajos de grado, tambin existen ciertas
diferencias en la presentacin formal una vez se han finalizado, tanto en la
modalidad de una investigacin de campo, como en la modalidad de un
proyecto factible. As, el Manual de Trabajos de Grado, de Maestra y Tesis
Doctorales (UPEL, 1998) precisa que, la presentacin del trabajo final de la
investigacin de campo contiene las siguientes secciones: Introduccin, el
planteamiento del problema, que puede incluir, el contexto o antecedentes del
estudio; los objetivos; la justificacin del mismo; el marco referencial; la
metodologa, que trata del diseo de investigacin, las variables e indicadores,
27

Metodologa

la poblacin y muestra, los instrumentos y el anlisis de los datos. Tambin,

las limitaciones, los resultados, conclusiones, recomendaciones y la lista de
referencias.
Diferencias entre proyecto de investigacin y proyecto factible.
CRITERIOS

PROYECTO DE INVESTIGACION

PROYECTO FACTIBLE

Finalidad

Indagar acerca de un
problema de investigacin
en un rea del conocimiento

Objetivos

Se definen objetivos de
investigacin.

Metodologa

Se emplean tcnicas e
instrumentos propios de la
investigacin.
Introduccin.

Proponer la solucin a un
problema de tipo prctico
o la satisfaccin de
necesidades de una
institucin.
Se definen objetivos de
accin, procesos o
actividades.
En cada etapa del proceso
se emplean diferentes
tcnicas.
Introduccin.

Planteamiento del problema,

Objetivos y Justificacin de
la investigacin.

Contexto de la situacin,
Objetivos y Justificacin
del proyecto.

Marco referencial.

Marco referencial.

Metodologa.

Metodologa.

Anlisis e interpretacin de
los datos.

Diagnstico de
necesidades.

Limitaciones.

Formulacin de la
propuesta.

Secciones para
su elaboracin

Resultados.
Anlisis de factibilidad.
Conclusiones.
Recomendaciones.
Recomendaciones.

Referencias.

Referencias.
Sin embargo, para el proyecto factible no expresa claramente como debe
presentarse la propuesta y el informe final, en virtud de lo cual se propone la
siguiente estructura formal.
Con base en las diversas concepciones, el proyecto factible se desarrolla a
travs de las siguientes etapas: el diagnstico de las necesidades, el cual

28

Metodologa

puede basarse en una investigacin de campo o en una investigacin

documental, planteamiento y fundamentacin terica de la propuesta; el
procedimiento metodolgico, las actividades y recursos necesarios para su
ejecucin y el anlisis de viabilidad o factibilidad del proyecto (econmica,
poltica, social, entre otros) y la posibilidad de ejecucin (Gonzlez, 1996;
Arias, 1998; UPEL, 1998; lvarez, 2001).
De all que, el informe final del proyecto factible se conforma con los siguientes
aspectos: Introduccin, contexto de la situacin, el planteamiento de la
necesidad, los objetivos y la justificacin del proyecto; el marco referencial, la
metodologa, el diagnstico de necesidades, la formulacin de la propuesta, el
anlisis de factibilidad, las recomendaciones y la lista de referencias. Adems,
en caso de que el proyecto refiera la evaluacin de propuestas, es necesario
incorporar la descripcin de los procesos, los resultados, las conclusiones y
recomendaciones. En consecuencia, el proyecto factible conforma un proceso
de planificacin en el cual la investigacin es una etapa, que le proporciona
informacin para sustentar la propuesta.
Algunos ejemplos de proyectos factibles manifiestan el contexto de las
necesidades hacia cuya satisfaccin estn diseados: Programa para la
formacin de microempresarios en las menciones de Contabilidad y Mercadeo
(Valderrama, 2001). Propuesta de estructura organizativa para una Unidad
Educativa. (Vera, 1993). Estudio de factibilidad y propuesta de diseo
curricular para crear la carrera corta de Educacin en las menciones de Artes
Industriales, Electricidad e Informtica en Instituciones Universitarias del
Estado Falcn (Snchez, 1998).

29

Anlisis Diseo y Desarrollo

Requerimientos Funcionales
Acerca de los requerimientos
La lista de requerimientos fue recolectada en diferentes entrevistas con el
personal del instituto de urbanismo, y en una visita al mismo. La identificacin
de los requerimientos se llevo a cabo usando las teoras y la metodologa
Volere descritas por James y Suzanne Robertson
(http://www.volere.co.uk/index.htm)
Restricciones del sistema
Restricciones del producto
Objetivo del producto
1. Proveer una herramienta para el manejo de:
Manejo de solicitudes de soporte
Inventario
Ayudas institucionales
2. Facilitar a los usuarios una interfaz fcil e intuitiva de utilizar.
Los clientes, y otros interesados
Jefe de la oficina de computacin
Coordinador Administrativo del Instituto de Urbanismo
Usuarios de la plataforma TI de la institucin
Usuarios finales y sus caractersticas
Los usuarios sern las personas que tengan acceso al sistema y consisten en:
Analistas de TI (incluido el jefe de la oficina de computacin).
Coordinador Administrativo.
Caractersticas de los Analistas de TI: Los analistas de las tecnologas de
informacin:

Persona capacitada en el uso de computadoras.

Con experiencia en la instalacin de los componentes necesarios de
aplicaciones.
Con experiencia en los diversos sistemas operativos usados, para lograr
una correcta configuracin del sistema.
Las personas sern responsables de los servidores.
Con un nivel de educacin de TSU, licenciatura, o equivalente, orientado
al uso o mantenimiento de computadoras y plataformas de TI.

Caractersticas del Coordinador Administrativo:

Posee conocimientos bsicos en el uso de computadoras.

Supervisa el proceso administrativo (inventarios) y se nutre de l (para
el seguro de los equipos).

Restricciones del proyecto

Restricciones Tcnicas

30

Anlisis Diseo y Desarrollo

El sistema debe ejecutarse en lnea, permitiendo el acceso a ciertos

dispositivos inalmbricos, para lo que se requiere cierta adecuacin
tecnolgica de la plataforma.
Requerimientos funcionales
El alcance del producto
El producto formara parte de la biblioteca de aplicaciones del instituto. Ser
utilizado para mejorar la calidad y supervisin de las actividades realizadas
por la oficina de computacin, tendr un subsistema de control de soporte de
requerimientos tcnicos, un subsistema de inventario y un subsistema de
informacin de funciones administrativas (control de ayudas institucionales).
El producto tendr diferentes vistas para los diferentes usuarios, de acuerdo
a su uso y funcin, el sistema poseer algunas caractersticas que permitan
el acceso inalmbrico a sus funcionalidades, en versiones beta o posteriores.
Requerimientos funcionales y de datos

Para los analistas de TI, en el subsistema de control de soporte:

o Permitir agregar los requerimientos de soporte de los usuarios.
Cada requerimiento de soporte deber indicar:
Nombre del cliente que solicita el soporte.
Tipo de problema (hardware, software, redes, servidores,
otro)
Breve descripcin del problema.
Fecha y hora de la solicitud.
Nombre del analista que recibe la solicitud.
o Obtener consultas de los requerimientos de soporte pendientes.
o Poder cerrar los requerimientos de soporte una vez cubiertos y
mantener una historia de los mismos. Al cerrar deber indicarse:
Fecha y hora del cierre.
Razn u origen del problema.
Breve descripcin de la solucin.
Nombre del analista que cierra el problema.
o Ser capaces de indagar soluciones anteriores a problemas
similares.
o Obtener listados de requerimientos solventados entre fechas.
Para los analistas de TI, en el subsistema de control de inventario:
o Poder agregar un activo cuando ste es adquirido. La informacin
guardada para cada activo deber contener, al menos:
Serial del equipo.
Etiqueta UCV (opcional)
Marca.
Modelo.
Tipo de activo (PC, porttil, impresora, switch)
Configuracin (detallada)
Financiamiento.
Destino
Proveedor

31

Anlisis Diseo y Desarrollo

Etiqueta local (IU, Insurbeca, Postgrado, CDCH)

Estado del bien:
Activo: El equipo est en uso, y operativo.
Desplegado: el equipo se encuentra en revisin por
parte del personal del IU (soporte).
Reparando: el equipo se encuentra fuera de las
instalaciones del IU para su reparacin.
Desincorporado: el equipo ha sido desincorporado de
los inventarios de la UCV o Insurbeca, aunque an se
encuentra en las instalaciones.
Retirado: el equipo, trs ser desincorporado, sale de
las instalaciones, este retiro lo realiza generalmente,
personal de mantenimiento de la facultad.
Poder modificar ciertas caractersticas de los activos una vez
ingresados al sistema, como ubicacin, algunos componentes.
Poder desincorporar y reportar como entregados, los activos que
ya no sean utilizados en la institucin.
Poder realizar consultas sobre activos.
el jefe de la oficina, en el subsistema de eventos administrativos:
Poder indicar la realizacin de un proceso de mantenimiento
preventivo. El mantenimiento debe realizarse dejando indicado lo
siguiente:
Fecha del mantenimiento.
Proveedor que realiza el mantenimiento.
Sobre que tipo de equipos se realiza el mantenimiento
(servidores, PC, impresoras).
Fecha estimada para el prximo mantenimiento.
Recibir alertas sobre el plazo entre mantenimientos.
Ser capaz de indicar la solicitud de una ayuda institucional,
indicando recaudos y equipos solicitados. Las ayudas deben
indicar:
Profesor encargado de la ayuda.
Organismo financiador.
Investigaciones que soportan la solicitud de ayuda o
recaudos entregados.
Monto general de la ayuda.
Fecha de aprobacin de la ayuda.
Equipos solicitados, que a su vez deber indicar:
Descripcin del equipo.
Monto.
Proveedor.
Fecha de solicitud de compra.
Fecha de ejecucin (cuando el organismo emite el
cheque).
Fecha de recepcin del equipo.
Poder ubicar activos en el inventario y consultar el estado de los
mismos (activo, en reparacin, desplegado, desincorporado o
retirado)

o
o

o
Para
o

o
o

32

Anlisis Diseo y Desarrollo

Para el coordinador administrativo:

o Poder listar el inventario, con un formato conveniente para su
utilizacin en la actualizacin de la pliza de seguros de los
equipos. Este listado deber indicar:
Serial del equipo.
Marca.
Modelo.
Tipo de activo (PC, porttil, impresora, switch)
Configuracin (detallada)
Etiqueta local (IU, Insurbeca, Postgrado, CDCH)

Requerimientos no funcionales
Apariencia y sensacin del producto
Fcil de entender y amigable.
Informacin distribuida amigablemente.
Requerimientos de uso
Fcil de aprender y fcil de usar para gente sin entrenamiento.
Intuitivo y grfico.
Errores amigables: El usuario debe entender perfectamente qu fue lo
que pas, y qu debe hacer a continuacin.
Destinado a los usuarios finales.
Requerimientos de desempeo
Rapidez media en la captura / recuperacin de datos.
Soportar varias transacciones, continuamente.
Confiable: se debe tratar de evitar errores tcnicos o de recuperarlos.
Disponible: El servicio debe estar disponible las horas de servicio de la
institucin.
Requerimientos operacionales
El sistema estar disponible en uno de los servidores de la institucin, y
ofrecer acceso a cualquier computadora dentro de la red local de la
institucin.
Requisitos de mantenimiento y portabilidad
El producto deber estar disponible para cualquier plataforma operativa,
independiente de OS y hardware.
Requerimientos de seguridad
Los datos de la aplicacin deben ser respaldados y deben ser ntegros
entre s.
Los usuarios finales debern poder acceder a la informacin durante las
horas de trabajo de la institucin.
Requerimientos polticos y culturales
Mantener el diseo de la interfaz de acuerdo a los requerimientos
institucionales, y de acuerdo al reglamento de colores especificado por la
Facultad de Arquitectura y Urbanismo (FAU).
De preferencia, la interfaz deber ser similar a los diseos usados por la
FAU.

33

Anlisis Diseo y Desarrollo

Requerimientos legales
Todo el Software del que dependa la aplicacin, deber estar bajo la
licencia de uso pblico GNU, tambin requiere disminuir los costos de
software para Servidor y para Base de Datos.

34

Anlisis Diseo y Desarrollo

Casos de Uso
Control de Requerimientos

2. Control de Requerimientos

Solicitar Soporte

Usuario
Spte Telefnico
uses

uses
Resolver Caso

Spte en Sitio
uses

Analista

Listar
Requerimientos

Reparacin
Proveedor

2.1 Solicitar Soporte

Solicitar Soporte

uses
Agregar
Requerimiento

Usuario

35

Anlisis Diseo y Desarrollo

2.2. Resolver Caso

Novedad
Spte Telefnico

uses
uses

uses
Resolver Caso

Spte en Sitio
uses

Analista
Proveedor
Reparacin

2.3 Listar Requerimientos

Rango de fecha
extends

extends
Listar
Requerimientos

Analista

extends

Administrador

Requerimientos
pendientes

36

Anlisis Diseo y Desarrollo

Inventario

Sistema de Inventario

Inventario
Analista

Servicios Generales

3 Inventario

AgregarActivo

Actualizar Activo
Analista

Desincorporar
Activo

Retirar Activo

Servicios Generales
Listar Inventario

Coordinador

37

Anlisis Diseo y Desarrollo

3.1 Agregar Activo

AgregarActivo

Analista

3.2 Actualizar Activo

Actualizar Activo

Analista

3.3 Desincorporar Activo

Desincorporar
Activo
Analista

3.4 Retirar Activo

Retirar Activo

Servicios Generales

3.5 Listar Inventario

ListarTodo
Listar Inventario
Dependend

Coordinador

Estado
Seguro

38

Anlisis Diseo y Desarrollo

Trmites Administrativos

39

Anlisis Diseo y Desarrollo

4.1 Registrar Trmite

RegistraTrmite

uses
Cotizacin

Administrador

4.2 Actualiza Trmite

uses

AvalTcnico

uses
Compra

ActualizaTrmite

uses
Cotizacin

Administrador

4.3 Cierra Trmite

CierraTrmite

Administrador

40

Anlisis Diseo y Desarrollo

Diagramas de Secuencia
Iniciar Sesion:

1.2.1

ADMINISTRADOR

BASE DATOS

SESION
VALIDA (ID)

AGREGAR (DATOS)

RESULTADO
AGREGA (DATOS)
OK

RESULT

1.2.1

2.1 CONTROL: SOLICITAR SOPORTE

41

Anlisis Diseo y Desarrollo

SOPORTE TELEFONICO:

ANALISTA

CLIENTE

NOVEDAD

CONTACTAR (CLIENTE)

SOLICITAR (INFO)

INFO
INDICACIONES

RESULTADOS
AGREGAR (NOVEDAD)

Solucin

Soporte Telefnico

SOPORTE EN SITIO:

42

Anlisis Diseo y Desarrollo

REPARACION:

4.1 REGISTRAR TRAMITE (SOLICITAR AYUDA)

SISTEMA

ADMINISTRADOR

NOVEDAD

PROVEEDOR

SOLICITAR (COTIZACION)

SOLICITUD
SOLICITUD APROBADA
ID

Registrar Trmite (Solicitar Ayuda)

43

Anlisis Diseo y Desarrollo

4.2 ACTUALIZAR TRMITE

SISTEMA

ADMINISTRADOR

NOVEDAD

PROVEEDOR

COTIZACION

SOLICITUD COMPRA (COTIZACION)

EMITE COMPRA
ORDEN DE COMPRA

SOLICITAR
ENTREGAR EQUIPO
AGREGAR ENTREGA

Actualizar Trmite

4.3 CERRAR TRMITE

44

Anlisis Diseo y Desarrollo

3.1 AGREGAR ACTIVO (3.2, 3.3, 3.4)

3.5 LISTAR

45

Anlisis Diseo y Desarrollo

Diagramas de Actividades
Iniciar Sesin

Ingresar Datos del Usuario

Valida no OK
Mostrar Mensaje de error
Valida OK

Asigna Nivel de Usuario

Administrar Usuarios
Agregar Cliente

Ingresar Cdula del Cliente

Administrar Usuarios
Agregar Analista

Ingresar Cdula del Analista

Analista
existe

Mostrar Mensaje de error

Nuevo cliente

Cliente
existe

Ingresar datos restantes

Mostrar Mensaje de error

Nuevo analista

Ingresar datos restantes

46

Anlisis Diseo y Desarrollo

Administrar Usuarios
Modificar Cliente

Administrar Usuarios
Modificar Analista

Ingresar Cdula del Cliente

Cliente
validado

Cliente
no
existe

Ingresar Cdula del Analista

Mostrar Mensaje de error

Analista
validado

Modificar datos

Administrar Usuarios
Eliminar Cliente

Ingresar Cdula del Analista

Ingresar Cdula del Cliente

Mostrar Mensaje de error

Cliente
no
existe

Marcar registro

Mostrar Mensaje de error

Modificar datos

Administrar Usuarios
Eliminar Cliente

Cliente
validado

Analista
no
existe

Analista
validado

Analista
no
existe

Mostrar Mensaje de error

Marcar registro

47

Anlisis Diseo y Desarrollo

Control de Requerimientos
Crear requerimiento

Control de Requerimientos
Resolver caso

Spte. Telefnico
Abrir Requerimiento

Equipo OK
Equipo no OK

Indicar Problema

Spte. en sitio

Generar Cdigo de caso

Cerrar caso

Equipo OK
Equipo no OK
Revisar equipo en taller

Desincorporar
Equipo OK
Equipo no OK

Equipo no OK
Actualizar inventario

Equipo OK

Inventario
Agregar Activo

Reparar equipo con proveedor

Actualizar inventario

Inventario
Modificar Activo

Ingresar Serial y Marca de activo

Activo existe
Activo no existe

Agregar datos adicionales del activo

Ingresar Serial y Marca de activo

Mensaje de error

Activo existe

Modificar datos del activo

Activo no existe

Mensaje de error

48

Anlisis Diseo y Desarrollo

Inventario
Desincorporar Activo

Ingresar Serial y Marca de activo

Activo existe

Activo no existe

Ingresar datos de la desincorporacin del activo

Mensaje de error

Inventario
Retirar Activo

Ingresar Serial y Marca de activo

Activo existe y est

desincorporado
Marcar el activo como retirado

Activo no existe
o no est
desincorporado

Mensaje de error

49

Anlisis Diseo y Desarrollo

Inventario
Desincorporar Activo

Indicar Cdigo de trmite y ente

Trmite existe

Mensaje de error

Trmite no existe

Agregar datos del trmite

50

Anlisis Diseo y Desarrollo

Diagramas de Estado

51

Anlisis Diseo y Desarrollo

52

Anlisis Diseo y Desarrollo

53

Anlisis Diseo y Desarrollo

Diagrama de Componentes

Usuarios
Soporte
Abrir de Requerimiento
Registro de Usuarios

Actualizar Requerimiento

Registro de novedades

Listar Requerimientos

Entrada

Trmites
Entrada
Registro de novedad

Registro de aval

Registrar Trmite

Actualizar Trmite

Inventario

Agregar Activo

Registrar Compra

Actualizar compra
Actualizar Activo

Registro de cotizacin
Listar Inventario

54

Anlisis Diseo y Desarrollo

Pantallas del Sistema

55

Conclusiones, Recomendaciones, Bibliografa y Referencias

Conclusiones
Al finalizar el presente trabajo se han obtenido resultados que expresan
situaciones que permiten y facilitan llevar a cabo las funciones principales de la
Oficina de Computacin, el estudio realizado ha conducido al desarrollo de
herramientas que proveen un control eficiente de las actividades de soporte e
inventario, y el seguimiento de las mismas. Los resultados, expresados en funcin
de la implementacin, se pueden determinar al momento de ser capaces de
evaluar las actividades realizadas a travs de estadsticas arrojadas por la
herramienta, as como al observar el control existente sobre las actividades
administrativas de la oficina.
A partir de esto, se han obtenido las siguientes conclusiones:

Se obtuvo un sistema de control de requerimientos que permite obtener

estadsticas, as como una base de conocimientos tcnicos que servir de
repositorio de casos tcnicos.

Se realiz un subsistema de inventario que permitir mantener actualizado

el listado de equipos para su uso pertinente, tanto de soporte como de
administracin.

El desarrollo produjo un subsistema de indicadores de eventos que facilita

el control de las actividades de mantenimiento a la plataforma tecnolgica
de la institucin.

El subsistema de inventario contiene, adems, un subsistema de manejo de

adquisiciones y desincorporaciones. ste lleva el control de los equipos
desincorporados o por desincorporar, as como de aquellos que han sido
adquiridos y que an no estn inventariados.

Se realiz el desarrollo del subsistema de trmites, que lleva control de las

solicitudes de ayudas institucionales en cuanto a la ejecucin de la misma,
y que permite un estrecho vnculo con el subsistema de inventario para
llevar facilitar su actualizacin.
56

Conclusiones, Recomendaciones, Bibliografa y Referencias

Recomendaciones

Todo el trabajo realizado no tiene significado ni trascendencia si no se desarrolla

una conciencia de funcionamiento, que haga que todos los actores se involucren
de manera constante con el sistema, debe realizarse una etapa de educacin para
que los usuarios comprendan la importancia de su rol en el mantenimiento de
cada uno de los subsistemas desarrollados.
Sin embargo, para que los usuarios sientan comodidad en el uso del sistema debe
proverseles de accesorios que faciliten sus actividades, algunas mejoras como la
adquisicin de un lector de cdigos de barras, con una aplicacin para la creacin
de etiquetas con este formato, para personalizar el inventario y facilitar las
operaciones sobre el mismo.
Es importante la revisin peridica de las estadsticas para poder tomar medidas
correctivas a las fallas detectables a travs de stas, como tiempos de respuesta
de los procesos de soporte o seguimiento a las solicitudes de ayuda.

57

Conclusiones, Recomendaciones, Bibliografa y Referencias

Referencias
Lewis 1994
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#Lewis1994
#Lewis1994
Cota 1994
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#Cota1994#
Cota1994
Jacobson 1998
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#Jacobson1
998#Jacobson1998
OMG
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#OMG1999#
OMG1999
UML
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#OMG1999#
OMG1999
M&R 1998
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#MR1998#M
R1998
MSF
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#Microsoft1
997#Microsoft1997
Booch 1998
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#Booch1998
#Booch1998
Microsoft 1997
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#Microsoft1
997#Microsoft1997
[1]. Groupware, Workflow and Intranets. Reengineering the Enterprise with
Collaborative
Software. Chaffey Dave, Ed. Digital Press, 1998.
[2]. Workflow: An Introduction. Allen Rob, Open Image Systems Inc.
[3]. Workflow and Internet: Catalysts for radical change, WfMC white paper,
1998.
[4]. Workflow Reference Model, WfMC white paper, 1995.
http://www.wfmc.org
58

Conclusiones, Recomendaciones, Bibliografa y Referencias

[5]. Workflow Technology, GFi Fax & Voi

Suzanne Robertson: http://www.volere.co.uk/index.htm

59

Conclusiones y Recomendaciones

Figuras
Figura 1. Estructura del Proceso Unificado Pgina 11
Figura 2. Arquitectura lgica de tres capas de una aplicacin cliente/servidor
Pagina 12
Figura 3. Arquitectura fsica de tres capas de la aplicacin cliente/servidor
Pgina 16
Figura 4. Elementos clave de un proceso de negocio Pgina 19
Figura 5. Modelo de referencia de Workflow- componentes e interfaces
Pgina 20
Figura 6. Representacin del proyecto factible en el mtodo sistmico
Pgina 26

55