Sunteți pe pagina 1din 103

Escuela de Ingeniera Industrial

EII590 Modelamiento de Sistemas de Informacin


Prof. Guillermo Bustos

[v150317]

Ejercicios de Integracin de Modelos


Los ejercicios indicados como RESUELTO o PARCIALMENTE RESUELTO tienen sus soluciones al
final de la gua.
1) Cules son los errores del DFD con relacin al DD?
f1
f3

f1 = a + b + c
f2 = a + { c }
X={b+(d)}
Y = { a + { b + {c } } }

P2
P1

P3

f2
Y

2) Qu puede decir con relacin al balanceo de los siguientes DFD y las definiciones del DD?
detalle de costos

3.1

3.3

evaluacion economica
proyecto evaluado
3.2

informe costos totales


4

resumen de costos

informe costos totales = detalle de costos + resumen de costos


proyecto evaluado = evaluacin econmica + beneficios no cuantitativos

3) Dados las siguientes porciones de DFD y DER. Indique los problemas de balanceo que presenta.
Y
A
C

X
B

4) [RESUELTO] Construya un DCla sin criterios avanzados de calidad, que represente estructuralmente un DPC.

5) [PARCIALMENTE RESUELTO] Suponga una pequea empresa de capacitacin que ofrece un


solo curso y tiene slo un profesor. Cada semana hbil es una instancia de la clase CursoSemanal.
El estado de reserva de una semana dada se registra en CursoSemanal.estadoReserva, que puede
contener los valores disponible, reservadoNoConfirmado y reservadoConfirmado. Cuando un
nuevo CursoSemanal se crea, es decir, cuando es colocado en el calendario, se le da el valor inicial
de disponible a estadoReserva. Un cliente puede hacer una reserva para una semana dada con o
sin la garanta de un pago inicial. Una garanta permite al cliente confirmar su reserva, en todo otro
caso slo tiene una reserva no confirmada.
a) [RESUELTO] Construya un DME para los valores definidos para estadoReserva.
b) El dueo de la empresa se da cuenta que algunas semanas tienen ms demanda que otras, definiendo as semanas populares para diferenciarlas de las semanas normales. El atributo esPopular
permite registrar la popularidad de un CursoSemanal. Slo las reservas confirmadas se permiten
en las semanas populares, pero para esto el cliente debe dar un pago inicial mayor. Se define mayor
como el pago de al menos un valor definido como pagoMnimo, asumiendo que pagoMnimo > 0.
Modifique el DME de a) para considerar esta nueva modalidad de la empresa.

6) [PARCIALMENTE RESUELTO] Suponga una empresa que vende artculos de las reas de aseo,
perfumera y plsticos en general (ASPEPLA Ltda.). En ASPEPLA trabajan 30 vendedores comisionistas que se especializan en estas reas. Para agilizar la labor de los vendedores, se sugiere que
ellos consulten directamente por lnea telefnica el stock de artculos que estn ofreciendo y sean
atendidos en forma automatizada. Para esto, deben previamente identificarse e indicar el cdigo del
(los) artculo(s) cuyo stock consulta(n) (el cdigo 0 indica que la consulta termin). En el caso que
se comprometan algunos artculos (el vendedor lo indicar por medio de la cantidad: si sta es 0, no
se hace reserva), stos son inmediatamente reservados y reducidos del stock hasta el mximo posible.

a) [RESUELTO] Construya el DTE que modele el proceso de control que permite a los vendedores
realizar sus pedidos.
b) [RESUELTO] Construya un DFD no jerarquizado para el sistema.
c) [RESUELTO] Construya el DPC para los procesos elementales del DFD de b).
d) Proponga un DER para complementar los modelos anteriores de acuerdo a la estrategia AEM.
Agregue los depsitos que sean necesarios al DFD, a fin de asegurar la consistencia mutua y asegure que las acciones del DTE concuerdan con los flujos de control del DPC.

7) [RESUELTO] Suponga la siguiente descripcin hecha por un funcionario de una oficina regional
de riego:
A esta oficina llegan muchas solicitudes de obras de regado de los agricultores de la regin.
En la seccin de estudios, se realiza una inspeccin ocular y se entrega un informe a la direccin sobre
la factibilidad inicial de la realizacin de la obra.
En el caso de que el informe sea auspicioso, la misma seccin elabora un anteproyecto con antecedentes que aportan los mismos agricultores ms otros que la seccin indaga a travs de sus tcnicos.
El anteproyecto elaborado, previa revisin por parte de la direccin, es enviado a la oficina
nacional de riego, donde ese elabora el proyecto definitivo (si coincide con las polticas nacionales de
regado) y se gestiona su financiamiento.
Con los proyectos aprobados y financiados que llegan de la oficina nacional, se elaboran las
bases tcnicas para realizar un llamado a propuesta para los contratistas consignados en la oficina regional.
Despus de la adjudicacin del proyecto a uno o ms contratistas, la seccin de supervisin y
control verifica el avance y provee los recursos financieros para la ejecucin del proyecto.
Se ha omitido deliberadamente de este problema la conclusin de los proyectos. Adems suponga, para simplificar, que no hay rechazos en la elaboracin de la factibilidad de las solicitudes.
Construya los modelos integrados, omitiendo el DD y las EP, para las estrategias de modelamiento enmarcadas en el paradigma de proceso.

8) Se requiere un sistema informtico para controlar el expendio de combustible, manejar el pago por
parte de los clientes y monitorear el nivel de los estanques.
Antes que un cliente pueda usar las bombas de auto-servicio, la bomba debe ser habilitada por
el supervisor. Cuando una bomba es habilitada, el motor de la misma se enciende (si es que ya no lo
est) cuando la manguera se retira de la bomba. Cuando es presionado el gatillo de la pistola, se cierra
un micro interruptor, el combustible se bombea y la manguera respectiva es ocupada. Cuando se suelta
el gatillo, la manguera es liberada. Existe tambin un micro interruptor en el enganche donde se coloca
la pistola para prevenir que se siga bombeando combustible hasta que la pistola sea nuevamente tomada. Una vez que la pistola es enganchada en la bomba, se entiende que la entrega de combustible est
concluida y la bomba es bloqueada. Si se presionara el gatillo en esta condicin no se bombea ms
combustible. Despus de un pequeo intervalo de espera, el motor de la bomba se apagar a menos que
la bomba sea nuevamente habilitada.
Un dispositivo de medida en la manguera de combustible enva una seal al sistema por cada
1/100 de litro expendido. En el visor de la bomba se muestra la cantidad expendida (volumen en litros)
y el costo.
3

Existen dos tipos de bombas. El tipo normal permite al usuario expender libremente el combustible. El tipo sofisticado de bomba permite al cliente especificar la cantidad en precio o el volumen de
combustible que ser expendido.
Las transacciones son registradas hasta que el cliente pague. La forma de pago puede ser en
efectivo, tarjeta de crdito o con cargo a una cuenta (otorgada a flotas de empresas). Como una forma
de promocin, se otorga un cupn de descuento de un valor fijo por cada $5.000 consumidos. Para el
caso en que el cliente se vaya sin pagar, el operador debe anotar en la transaccin cualquier informacin disponible (por ejemplo: patente del auto). Al final del da las transacciones son archivadas y pueden ser usadas para consultas especficas de la seccin de ventas.
Actualmente, se venden 2 tipos de combustible (93 octano con y sin plomo) expendidos por 5
bombas. Cada bomba se alimenta de uno de los 2 estanques subterrneos, uno para cada tipo de combustible. El nivel del estanque no debe bajar del 4% de su capacidad. Si esto ocurriera las bombas que
extraen el combustible del estanque no pueden operar.
Modele el sistema con la estrategia de entidades dinmicas. Se sugiere comenzar identificando
las entidades dinmicas y construyendo sus ciclos de vida, seguidamente debe desarrollarse el DER y
finalmente el DFD.

9) Dado el siguiente CU y DoCU asociada:


DCU

Escenario principal de la DoCU


Sistema Ventas

Hacer Pedido

1.
2.
3.
4.
5.
6.

Cliente

7.
8.
9.
10.
11.
12.
13.
14.

El CU se inicia cuando el cliente quiere hacer un pedido.


Sistema solicita datos del cliente.
Cliente ingresa su nombre y direccin.
Sistema solicita productos a pedir.
Cliente ingresa los cdigos de productos y las cantidades que desea pedir.
Sistema le provee una descripcin de los productos y el precio de
cada uno.
Sistema muestra el precio total de los productos ingresados.
Sistema solicita datos del pago.
Cliente ingresa los datos para pago con tarjeta de crdito.
Cliente confirma el pedido.
Sistema verifica los datos, guarda el pedido como pendiente y enva los datos del pago al sistema contable.
Sistema contable aprueba datos de pago.
Sistema marca el pedido como confirmado enviando al cliente el
nmero de su pedido.
El CU termina.

Indique los errores y las omisiones que presenta el siguiente DAct y proponga uno corregido.

Ingresar
Nombre y
Direccin

Ingresar
Cdigo
Producto

Desplegar
Descripcin
Producto y Precio

Ingresar Datos
Tarjeta de
Crdito

Enviar Datos
de Pago a
Contabilidad

Confirmar
Pedido

Marcar Pedido
Como
Confirmado

Verificar Datos
Pedido

Desplegar
Nmero Pedido

Recalcular
Total Parcial

10) Suponga un pequeo sistema de pedidos, simplificado deliberadamente, que opera de la siguiente
manera. La empresa es una distribuidora que atiende pedidos de clientes previamente registrados.
Cuando se recibe un pedido se verifica el stock, caso alguno de los productos no est, se deja el pedido pendiente hasta completar todos sus productos. Si todos los productos estn, se rebaja el stock
respectivo y se emite una factura al cliente con los productos. Peridicamente se revisa el stock para verificar los stocks mnimos y los pedidos pendientes. Los productos son solicitados y recibidos
de los proveedores respectivos. Si alguno de los pedidos pendientes tiene todos sus productos en
stock, se trata como un pedido normal.
Se pide construir los modelos esttico, dinmico y funcional para las estrategias de integracin:
AEM, ES, ED y UML.

11) [PARCIALMENTE RESUELTO] Dado el siguiente DCom integrado:

Temporizador

pas1Minuto
ajustarMinutos

parpadearMinutos
m: Minuto

incrementarMinutos
incrementarHoras
selectPresionado

ajustarHoras
c: Comando

Usuario

setPresionado

h: Hora
incrementarHoras
mostrarHoras

parpadearHoras

p: Pantalla
mostrarHorasMinutos

mostrarMinutos

a) [RESUELTO] Construya el DME de la clase ms compleja, segn el DCom dado.


b) Construya el DME de la 2 y 3 clases ms complejas, segn el DCom dado.
c) Qu particularidad presenta el DME de la clase Pantalla? A qu puede deberse?

12) [RESUELTO] Suponga un sistema de apoyo a una pequea biblioteca que opera de la siguiente
forma:

La biblioteca presta libros y revistas a usuarios, que han sido previamente registrados, de igual
forma que los libros y revistas.
La biblioteca tambin se encarga de comprar nuevos ttulos. Se compran mltiples ejemplares
de aquellos ttulos ms populares. Por otro lado, se descartan los libros y revistas ms antiguos,
ya sea por estar desactualizados o por su mala condicin.
En la biblioteca trabaja un empleado que interacta con los usuarios y cuyo trabajo es apoyado
por el sistema.
Un usuario de la biblioteca puede reservar un libro o revista que no est disponible en el momento y retirarlo despus. La reserva es cancelada cuando el usuario se lleva el libro o revista o
a travs de una cancelacin explcita.
La biblioteca puede, en cualquier momento, crear, actualizar y eliminar datos sobre los ttulos,
usuarios, prstamos y reservas.

Construya los DCU, DCla, DCom y DME (para la clase con ms interacciones) para este sistema, obviando los argumentos de todas las operaciones, mensajes, eventos y acciones.

13) Una estacin de servicio posee dos bombas, ambas abastecidas por un nico estanque. Las bombas
pueden utilizarse en todo momento que estn disponibles, a excepcin de aquellos en que el estanque se encuentra vaco o se est llenando, lo cual se hace aproximadamente cada cinco das, para
que la interrupcin de la atencin a clientes sea mnima. Cada vez que llega un cliente, si alguna de
las bombas est libre, se ingresa la cantidad solicitada por el cliente. Si todo est funcionando correctamente, es decir, el estanque tiene combustible, se coloca la manguera en el auto y se libera el
seguro de sta, con lo que empezar a funcionar el motor de la bomba, el que succiona la bencina
desde el estanque y, por lo tanto, comienza el flujo de bencina en la bomba en uso. Cuando se alcanza la cantidad solicitada por el cliente, el flujo se corta automticamente, lo que significa que la
bomba deja de funcionar y el motor se detiene.
a) Represente este problema utilizando slo la visin dinmica de UML: DME y DSec.
b) Represente este problema utilizando slo la visin dinmico-funcional de UML: DCU y DAct.
c) Compare los modelos resultantes de a) y b) Cul recomendara Ud. y en qu casos? Por qu?

14) Problema del Sistema de La Trasnociatta para modelamiento en grupo:


El servicio de entrega de pizzas La Trasnociatta ha decidido crear un servicio indito en el
pas: instalar una lnea 800 las 24 horas (Teleciatta) que permite que clientes registrados hagan pedidos
y sean atendidos electrnicamente todos los das del ao y en cualquier horario.
Para que un cliente pueda usar este servicio, deber previamente inscribirse en La Trasnociatta, pagando una cuota de inscripcin (no muy alta), y entregando sus datos: nombre, telfono, direcciones de entrega (pueden ser varias), direccin postal y el tipo y nmero de su tarjeta de crdito. A
cambio, la pizzera le proporcionar una clave de cliente de 6 dgitos (secreta) y una carta donde aparece el nombre del cliente, el listado de direcciones de entrega con su nmero respectivo (1, 2, 3, ...), un
listado codificado de 3 dgitos con los tipos de pizzas que pueden solicitarse, los tamaos disponibles
(1=individual, 2=media, 3=familiar), los precios vigentes respectivos, los perodos de recargo y oferta,
y algunas observaciones. Adems, se le avisa que si desea modificar sus datos (incluso su clave secreta)
podr hacerlo personalmente en cualquier momento.
Actualmente existen tres perodos que determinan los precios de las pizzas, los cuales debern
ser considerados por este nuevo servicio:
Normal: Lunes a Sbado de 8:00 a 12:00 y de 16:00 a 20:00.
Recargo (+10%): Lunes a Sbado de 12:01 a 15:59 y de 20:01 a 02:00.
Oferta (-15%): En los horarios restantes, das Domingo y feriados las 24 horas.
Cuando un cliente registrado llame a la Teleciatta, el servicio responder con una grabacin:
Usted ha llamado al servicio electrnico Teleciatta, por favor digite su clave de cliente para ser identificado. El cliente deber entonces digitar su clave secreta. Si el cliente es efectivamente identificado,
se le preguntar por el cdigo del tipo de pizza que quiere, el tamao, la cantidad de pizzas y si quiere
7

pedir de otro tipo. Esto se repetir hasta que el cliente diga que no quiere pedir ms pizzas. Se entregar
el precio total del pedido (incluyendo los recargos o descuentos, generales y/o por cliente 1, segn corresponda) y se pedir su confirmacin. Si el pedido no fuera confirmado, el sistema se despedir y
desconectar.
Si ocurre cualquier error en la digitacin de los cdigos (clave del cliente, tipo, tamao y cantidad de pizzas, y en las confirmaciones), ya sea porque no corresponden, o son ingresados muy rpida o
lentamente, se le pedir al cliente que repita la digitacin. Si el error se repite, el sistema explicar:
"Disculpe, ingreso incorrecto. Srvase llamar nuevamente." y se desconectar.
Una vez confirmado el pedido, el servicio solicitar el nmero de la direccin de entrega y finalmente el servicio explicar: El total ser cargado en su tarjeta de crdito y la entrega se har en
un mximo de 30 minutos. Muchas gracias por su pedido. Esperamos poder atenderlo nuevamente.
Finalmente, el sistema se desconectar, confirmar que la tarjeta de crdito est habilitada (sin problemas) y si es as, pasar los datos del cliente y del pedido a la cocina, de donde ser despachado para la
entrega. Si la tarjeta tuviese inconvenientes, deber anularse el pedido y avisar al cliente del problema
existente.
Los pedidos son clasificados en reas de acuerdo a la direccin de entrega. Existen por el momento 8 reas de entrega distintas, siendo todas atendidas por repartidores de la Teleciatta, los que deben conocer cada una de ellas para evitar perderse y demorar la entrega de pizzas. En principio la pizzera pretende entregar centralizadamente todos los pedidos, pero quiere evaluar la posibilidad de a
futuro abrir puestos con cocina y repartidores en las reas con mayor demanda, a los cuales traspasar
los pedidos tomados centralizadamente. Para evaluar esta posibilidad, se necesitar llevar un detalle de
los pedidos por rea y de los tiempos de entrega de cada pedido. Por esto, cada repartidor debe llevar
en su entrega el pedido, la boleta con el detalle y totales, el recibo de pago de la tarjeta de crdito 2 y
una pequea planilla (generada por el sistema) donde el cliente deber anotar la hora de recepcin del
pedido, si recibi el pedido dentro de los 30 minutos (S o No) y su firma. Los repartidores ganarn un
5% de comisin por cada pedido entregado dentro del plazo. En todo caso, como esta planilla podra
ser alterada por los repartidores, cada cierto tiempo la pizzera llamar aleatoriamente a clientes de las
diferentes reas para consultarles por la satisfaccin del servicio.
Trimestralmente, la pizzera modifica sus listas de pizzas y enva a sus clientes listados con
nuevos precios, ofertas y tipos de pizzas. Adems, se le pide una evaluacin del servicio que el cliente
puede enviar a La Trasnociatta para que sta pueda mejorar sus servicios.
Para facilitar estas modificaciones, se utilizan dos informes: el informe trimestral de preferencias y el informe trimestral de horarios. El primero contiene un ranking de todas las pizzas pedidas de
acuerdo al total solicitado y al tamao escogido en cada uno de los pedidos, tal que las pizzas menos
preferidas podran reemplazarse por otras nuevas. El segundo incluye detalladamente el nmero total

Se otorga un descuento adicional de 10 15% a los clientes que tengan un alto consumo de pizzas, lo cual se determina
mediante el informe mensual de consumo.
2
Si el cliente lo solicita, se le puede enviar a su direccin postal un resumen de los pedidos que haya realizado durante el
ltimo mes, donde se incluya la fecha, hora y precio de cada pedido para que pueda verificar los cargos de su tarjeta de
crdito.

de pizzas solicitadas (no importa el tipo), por hora y por da, el cual se utiliza para evaluar si es necesario realizar modificaciones a los perodos de recargo.
Por ltimo, el ltimo da de cada mes debe generarse el informe mensual de consumo, el que
contiene todos los clientes que han hecho pedidos durante el mes, especificando el nombre y la direccin del cliente, adems del nmero de pizzas que pidi. Los clientes que hayan pedido sobre 20 pizzas
recibirn un descuento adicional de 15% y a los clientes que hayan pedido entre 10 y 20 pizzas se otorgar un descuento de 10%. Este descuento se considerar automticamente en todos los pedidos que
realicen en el mes siguiente, sin embargo, cabe destacar que los descuentos no son acumulables, es
decir, se renuevan mes a mes.

15) Problema de la Biblioteca Universitaria para modelamiento en grupo:


1 Antecedentes
Una biblioteca es una instancia de servicio que tiene una papel fundamental en instituciones de
educacin superior. Su propsito puede concebirse desde una simple entidad que disponibiliza informacin para los usuarios, hasta uno en que desempea un rol activo en la formacin de las personas.
El recurso bibliogrfico debe ser administrado por la biblioteca con conceptos de equidad y eficiencia, es decir, que pueda entregarse a todo el que lo requiera y al mismo tiempo que tal recurso no
sea desperdiciado. No es de extraar entonces que los dos principales objetivos que pueden asignarse a
una biblioteca son los de maximizar la satisfaccin de todos los usuarios, independientemente de sus
necesidades bibliogrficas, como as tambin el de maximizar la utilizacin de este recurso.
Desde el punto de vista del usuario, parece ser la funcin de prstamo la nica que justifica la
existencia de una biblioteca, sin embargo existen diversas otras funciones que la apoyan y que no por
ser menos visibles son menos importantes. Entre estas funciones se encuentran las de compra y clasificacin de material nuevo, como as el anlisis y descarte del material no utilizado.
2 Sistema de Informacin a Ser Modelado
El sistema de informacin a ser modelado considera principalmente las funciones de prstamo
de libros de baja y alta demanda, material de consulta y la hemeroteca (prstamo de revistas). Tambin
se consideran las funciones de adquisicin y descarte de material bibliogrfico.
Deben mantenerse los datos sobre cada libro en particular que forma parte del acervo. Consignando todos sus datos se facilita posteriormente la consulta de los mismos ya sea por cdigo (usando el
sistema decimal de materias de Dewey), autor, ttulo, nmero de inventario, tema, ao, editora, otros y
combinacin de las anteriores. Todo esto es vlido para los libros de alta y baja demanda y el material
de consulta.
Aunque no es muy comn en los libros de baja demanda y en el material de consulta, existen
varios ttulos que poseen ms de una copia. Tambin es posible encontrar versiones del mismo libro en
diferentes idiomas (lo ms comn es en ingls y espaol) o an contar con diferentes ediciones del ttulo. Eventualmente existen por ejemplo, ttulos traducidos de una edicin anterior simultneamente con
la nueva edicin en el idioma original.

Los plazos de prstamo para los libros de baja demanda varan segn el tipo de usuario. Para
acadmicos, los libros se prestan por 30 das corridos, siendo que no tienen lmites de cuntos libros
pueden tener en prstamo. Los alumnos y funcionarios en general tienen un plazo de entrega de 7 das
corridos, siendo que no pueden tener en su poder ms de 5 libros al mismo tiempo. La excepcin son
los alumnos memoristas a los que se les quita la restriccin del nmero de libros.
Bajo el rgimen de prstamo de libros de alta demanda, stos deben ser devueltos hasta el medioda del da hbil siguiente y slo se prestan para la casa a partir de esa misma hora. En las maanas el prstamo es en sala. Este tipo de prstamo es slo para los alumnos (incluyendo memoristas).
Con respecto a los libros en este rgimen de prstamo, siempre se tiende a mantener la ltima
versin en espaol, sin embargo si existe una versin ms reciente en el idioma original se incorporan
algunas copias a este tipo de prstamo.
Dado el intenso uso de estos libros, stos se deben mantener en general con tapas duras y encuadernacin cada vez que lo requieran. Esto les permite una mayor durabilidad. Lo mismo ocurre con
aquellos libros de baja demanda pero mal tratados.
Las multas por atraso de entrega para todos los libros se fijan en base la valor de 2 pasajes de
locomocin colectiva (hoy fijado arbitrariamente en $300). A partir del tercer da de atraso se cobra
una multa adicional fija de 10 pasajes ($1500). La multa adicional no se aplica para el caso de los libros
de baja demanda. Mientras un alumno no haya devuelto sus libros ni cancelado sus multas tiene los
prstamos suspendidos en la biblioteca, salvo indicacin en contrario del jefe de biblioteca.
Existe tambin el denominado material de consulta que slo se presta en sala. Este material corresponde generalmente a catlogos, diccionarios, directorios, ndices y afines que sirven como medio
rpido de consulta.
La hemeroteca permite la libre consulta del material en sus salas (como en realidad sucede con
todo el material con la nica restriccin de los libros de alta demanda). Sin embargo, las revistas se
prestan (hasta un mximo de 10 ejemplares) bajo el mismo rgimen de los libros de alta demanda.
En la hemeroteca existen diversas publicaciones peridicas: diarios, semanales, quincenales,
mensuales, bimensuales, etc. Existen algunas publicaciones que eventualmente funden dos o ms ediciones en un slo ejemplar de mayor porte. La biblioteca debe mantener toda la informacin de la publicacin y debe estar atenta a los plazos para renovar las suscripciones.
El orden de todo el material bibliogrfico es hecho por tipo:
los libros de alta demanda son ordenados por autor en una seccin separada y sin acceso de
pblico;
los libros de baja demanda son distribuidos, de acuerdo a la clasificacin de materias y dentro de cada materia por autor, en estanteras de acceso libre al pblico;
el material de consulta es ordenado por ttulo en una seccin separada, tambin de acceso libre al pblico; y
las revistas son separadas por tema y ordenadas por ttulo y en forma cronolgica en estanteras de acceso restringido al pblico.
10

La adquisicin de nuevos textos y el descarte anual de textos se hace en base al movimiento


histrico de prstamos. Adicionalmente los acadmicos pueden indicar la compra de textos nuevos y
tambin sugerir la inclusin de textos bajo el rgimen de alta demanda. La biblioteca se reserva el derecho de ampliar el nmero de copias de algn texto si as lo amerita la demanda. Las compras son
hechas directamente por la biblioteca con indicacin a contabilidad para realizar los pagos. Lo mismo
sucede con la suscripcin de nuevas revistas y las renovaciones peridicas.
Libros candidatos a descartar son aquellos que no han sido prestados durante el ltimo ao. Sin
embargo, se consulta a los acadmicos del tema en cuestin para confirmar si pueden descartarse. Los
libros descartados que an se mantienen en buen estado son donados a bibliotecas pblicas de la regin. Las revistas no son dadas de baja salvo que su estado general as lo exija.
El jefe de biblioteca debe conocer la actividad global que se lleva a cabo en la biblioteca. En este sentido le sera muy til contar con informacin de cul es el volumen de prstamos, adquisiciones y
descartes, en base al tipo de usuario, tipo de prstamo y para cualquier perodo que solicite. Asimismo
le interesa conocer la proporcin de solicitudes de prstamo efectivamente satisfechas y el tiempo de
permanencia promedio de los distintos tipos de recurso bibliogrfico y para diferentes perodos de
tiempo. Con esta informacin le es posible asignar mejor los recursos humanos, financieros y materiales con que cuenta la biblioteca para el logro de sus objetivos.

16) Problema del Juzgado de Letras para modelamiento en grupo:


1 Antecedentes
La Constitucin Poltica del Estado de Chile establece que la funcin del Poder Judicial es la de
... conocer de las causas civiles y criminales, de resolverlas y de hacer ejecutar lo juzgado..." (Artculo 73 de la Constitucin Poltica del Estado de Chile.) Esta funcin es delegada en forma exclusiva en
el Poder Judicial, prohibindose la intervencin de los dems poderes del estado en ella.
La Constitucin establece tambin la obligacin del Poder Judicial de resolver todos los asuntos
que se le presenten (principio de inexcusabilidad), y confiere al Poder Judicial potestad de imperio sobre las autoridades y la fuerza pblica para hacer cumplir sus resoluciones.
El sistema judicial chileno se organiza en tres niveles jerrquicos. En el nivel superior se encuentra la Corte Suprema, bajo cuya supervisin se estructura todo el sistema judicial. Asume las funciones de hacer efectiva la supremaca constitucional, proteger las garantas constitucionales, uniformar
la jurisprudencia y, en general, servir de tribunal de segunda instancia en las causas en que las Cortes
de Apelaciones funcionan como tribunales de primera. Le corresponde la superintendencia directiva,
correccional y econmica sobre todos los Tribunales de la Repblica.
Las Cortes de Apelaciones son tribunales dependientes directamente de la Corte Suprema. En
segunda instancia conocen las causas civiles y criminales, as como las no contenciosas que hayan resuelto en primera instancia los jueces de letras de su jurisdiccin. Le corresponden tambin funciones
administrativas, econmicas y disciplinarias sobre los tribunales de su territorio jurisdiccional, que coincide con el de una regin, o parte de ella.

11

Bajo la supervigilancia de las Cortes de Apelaciones se encuentran los Juzgados de Letras, que
son tribunales ordinarios de primera instancia. Estn constituidos por un juez letrado, un secretario y un
nmero variable de funcionarios. Se organizan en funcin del territorio jurisdiccional, esto es, ejercen
sus atribuciones en una porcin del territorio de la Nacin, que, por lo general, coincide con una comuna o agrupacin de comunas. Tienen habitualmente jurisdiccin comn (conocen todo tipo de asuntos),
pero en algunos centros urbanos se han creado juzgados especializados en materias penales, civiles, de
menores y del trabajo.
A estos Tribunales les corresponden diversas funciones, distinguindose dos grandes clases de
actividades: jurisdiccionales y administrativas.
La actividad jurisdiccional dice relacin con el ejercicio de la jurisdiccin que tienen los tribunales. Es decir, representa el poder de administrar justicia que poseen los tribunales judiciales. Especficamente, consiste en las actuaciones procesales y decisiones de orden jurdico adoptadas por el personal del tribunal durante la tramitacin procesal de las causas judiciales.
Por actuaciones procesales se entienden las diligencias realizadas en cumplimiento de los procedimientos establecidos por ley para regular la tramitacin de los procesos judiciales. Algunos ejemplos de diligencias son los siguientes:

realizar comparendos,
realizar pruebas testimoniales,
efectuar testificaciones,
dictar providencia correspondiente a escritos ingresados al tribunal,
acoger o rechazar lo pedido por las partes, y
dictar sentencias.

Por su parte, la actividad administrativa dice relacin con la manutencin y funcionamiento del
tribunal. Consiste en la asignacin, manutencin y control de los recursos materiales, financieros y
humanos de que dispone un tribunal para funcionar y cumplir sus objetivos.
2 Sistema de Informacin a Ser Modelado
El sistema de informacin a ser modelado consiste en un conjunto de funciones que permiten
operar ms eficientemente un juzgado de letras desde el punto de vista del seguimiento de las causas
llevadas en l. Adems debe permitir obtener una buena visin global de la actividad realizada en el
mismo, la cual puede ser detallada en el grado en que se desee.
El modelo de sistema de informacin debe tener amplia aplicabilidad, logrando una independencia del tipo de juzgado en que se implante, y por ende, del tipo de causas judiciales que son procesadas en l.
Las causas son tipificadas en criminales, laborales, alcoholes, civil voluntaria, civil contenciosa,
menores civil y menores crimen. Dependiendo del tipo de juzgado, es el(los) tipo(s) de causa(s) que se
lleva(n). Sin embrago, en el caso de juzgados mixtos (que son los ms numerosos), stos pueden recibir
causas de todo tipo.

12

Las causas en general pueden contemplar varias materias (o delitos), pero por definicin deben
poseer una materia principal que tipifica la causa, por ejemplo: una causa puede contemplar un homicidio y una lesin menor, siendo la primera materia la que tipifica la causa como criminal y como homicidio. Las materias o delitos estn relativamente estandarizados y pueden ser codificados para facilitar
su clasificacin y posterior toma de estadsticas. No es poco frecuente que una causa cambie de materia
o que la materia principal pase a ser secundaria y una de las secundarias pase a ser principal.
Aparte de las causas existen los exhortos que describen diligencias que el juzgado debe realizar
a peticin de otro juzgado del pas. Cuando los exhortos llegan deben ser registrados consignando la
fecha del ingreso, el juzgado y rol de origen. Cada exhorto trata de una nica materia.
Cuando se recibe una causa, sta es ingresada, tipificada y mantenida posteriormente por un
funcionario denominado actuario, el cual le asigna un rol identificador, anotando el inicio de su tramitacin y todas las diligencias que se lleven a cabo dentro de sa y eventuales futuras tramitaciones. Cada diligencia que registra el actuario debe considerar la fecha en que fue solicitada, la fecha en que fue
efectivamente realizada, el responsable por la misma y el detalle correspondiente. La forma en que se
llevan las diligencias en una causa es la misma que en un exhorto con la diferencia que no existe un
actuario designado a cargo del exhorto.
Las diligencias estn tambin tipificadas, por tanto y dependiendo del tipo de causa, cada nueva
diligencia debe enmarcarse dentro de los tipos que le correspondan.
Cabe hacer notar que una diligencia solicitada en un juzgado para ser realizada fuera de su jurisdiccin se transforma en un exhorto para el juzgado receptor. Por tanto, cada juzgado solicita tambin diligencias que sern exhortos para otros juzgados.
Cada tramitacin de una causa debe tener un trmino o sentencia de responsabilidad del juez.
Cada tipo de causa tiene motivos de trmino propios que el juez puede invocar. Por ejemplo, una causa
puede ser archivada por falta de antecedentes, esto provoca el trmino de una tramitacin, sin embargo
tiempo despus puede ser aportado un nuevo antecedente que obliga a iniciar una nueva tramitacin.
Cada tramitacin es siempre iniciada por un denunciante (por ejemplo Carabineros o Investigaciones).
La sentencia es redactada por el juez considerando todos los antecedentes y diligencias de la
causa. Es importante entonces contar con una buena disponibilidad para consultar todos los datos que el
juez requiera sobre la causa, as por ejemplo, debe ser posible acceder a:

tramitaciones,
diligencias,
materias que trata, y
partes que involucra (con su RUT, nombre completo, direccin, profesin, estado civil y nacionalidad).

Esta misma facilidad de consulta de datos que dispone el juez puede entregarse a quien lo solicite con expresa excepcin de aquellas causas que por su naturaleza tengan orden de no informar. Los
actuarios son los nicos responsables por cualquier adicin, modificacin o eliminacin de registros de
una causa.

13

Los tipos de partes involucrados en una causa dependen del tipo de esta ltima. La siguiente
tabla muestra esta dependencia.
PARTE

Querellante

Querellado

Demandante

Demandado

Denunciante

Denunciado

Infractor

Menor

CAUSA
Criminal
Laboral

X
X

Alcoholes
Civil Voluntaria

Civil Contenciosa

Menores Civil

Menores Crimen

En el juzgado las causas son indistintamente identificadas por el rol o por el apellido de ambas
partes. Por ejemplo, una causa puede ser identificada como la 438 o como la Prez y Garca. Dependiendo de la modalidad que adopte el juzgado, el expediente que contiene toda la documentacin de
la causa puede ordenarse por cualquiera de estos dos criterios. En el caso de juzgados mixtos, las causas deben clasificarse primero por el tipo.
Los actuarios deben tambin elaborar dos informes peridicos estandarizados denominados Informe Bimensual y Informe de Causas Terminadas. El primero muestra la ltima diligencia realizada para cada causa adems de la diligencia consignada como ltima en el Informe Bimensual anterior.
De esta forma es posible determinar si existe avance en la tramitacin procesal de las causas. El Informe de Causas Terminadas es emitido mensualmente y muestra el motivo de trmino de cada una de las
causas terminadas en el mes considerado. Ambos informes son de responsabilidad del juez y por tanto
l debe preocuparse por su veracidad y correctitud.
Los ministros de la Corte de Apelaciones a la cual est subordinado el juzgado, solicitan espordicamente informes estadsticos que muestren los ingresos y trminos de causas para un periodo de
tiempo cualquier. Estos informes pueden ser solicitados por:

tipo de causa,
materia,
motivo de trmino, y
combinacin de los anteriores.

Con esta informacin la corte de apelaciones puede formarse una idea de la actividad de los
juzgados de su jurisdiccin. El propio juez tambin solicita informes estadsticos como los elaborados
para la corte de apelaciones pero con un mayor detalle, incluyendo tambin a los actuarios y las diligencias.
Para una mejor gestin de su juzgado, el juez debe contar tambin con estadsticas que muestren
la duracin promedio en das de las causas llevadas (por ejemplo bajo la forma de un histograma de
frecuencias) y los exhortos, que representan una carga adicional recibida de otros juzgados.

14

No se cuenta con una definicin de buenos indicadores de eficacia y eficiencia que este sistema
de informacin pueda generar. Parte de este problema es incluir tambin una proposicin de un indicador de cada categora en la forma de informes estadsticos del tipo indicado ms arriba.

17) [PARCIALMENTE RESUELTO] Problema del Sistema Telecom de Conmutacin Telefnica para
modelamiento en grupo:
1 Antecedentes
La empresa de telecomunicaciones Telecom se ha propuesto ser lder en servicios e infraestructura y la preferida por los clientes, constituyendo, al mismo tiempo, un apoyo indispensable a la competitividad, desarrollo y bienestar del pas.
Enmarcado en un mundo ya prcticamente sin fronteras en materia de telecomunicaciones, Telecom define sus estrategias en un ambiente de creciente globalizacin de los mercados y de convergencia de diferentes industrias: telecomunicaciones, informtica y entretencin.
En el competitivo mercado nacional de las telecomunicaciones, la participacin de Telecom depende casi exclusivamente de la calidad del servicio al cliente. Uno de los recursos fundamentales para
otorgar el servicio de telecomunicaciones es el sistema de conmutacin telefnica.
Es as que se desea definir un sistema de conmutacin telefnica que permita asegurar un nivel
mnimo de servicio al cliente (o suscriptor), es decir, que adems de otorgar la funcionalidad esperada,
pueda medirse su desempeo para as perfeccionarlo continuamente.
2 Sistema de Informacin a Ser Modelado
Un conmutador conecta suscriptores entre s. El suscriptor que llama se denomina suscriptor A.
Cuando este suscriptor marca un nmero en su telfono, el conmutador analiza los dgitos y busca la
lnea del suscriptor llamado. Este ltimo suscriptor es denominado suscriptor B. El conmutador conecta
entonces las lneas de los dos suscriptores, de tal forma que puedan conversar entre ellos. Cuando la
conversacin termina, ambos suscriptores cuelgan sus auriculares y esto hace que el conmutador desconecte las dos lneas. Normalmente, un suscriptor puede ser tanto un suscriptor A como B, pero en
una llamada telefnica especfica slo puede desempear uno de estos roles.
Cada unidad conectada al sistema de conmutacin es llamada un dispositivo. Una lnea hacia o
desde un suscriptor, por ejemplo, es un dispositivo. Esto significa que cada suscriptor especfico se
conecta a un cierto conmutador. Cada suscriptor tiene dos dispositivos fsicos asociados: una lnea suscriptor A y una lnea suscriptor B. Estos dispositivos son usados para hacer y recibir llamadas, respectivamente. Dado que no es posible que un solo conmutador maneje una red grande de telecomunicaciones, algunos dispositivos pueden ser tambin lneas de llegada o lneas de salida para otros conmutadores de acuerdo a la siguiente figura.

15

lneas suscriptor A

Conmutador

lneas de entrada

lneas suscriptor B

Conmutador

lneas de salida

Conmutador

Una lnea de entrada est conectada a un suscriptor A en otro conmutador, y la lnea de salida
dirige la llamada a un suscriptor B en otro conmutador. Cuando un suscriptor quiere llamar a un suscriptor conectado a otro sistema de conmutacin, se usan las lneas de salida del sistema para conectarse a las lneas de entrada del otro sistema.
Una ruta es un conjunto de lneas de salida, todas en una direccin especfica, como por ejemplo las lneas de un conmutador a otro. Para comunicarse con otro sistema, el sistema Telecom debe
escoger una lnea de salida de la ruta en esa direccin. No interesa cul es la lnea de la ruta que se
usar, slo debe escogerse una que no est ocupada.

Algunas consideraciones importantes:


Un suscriptor tiene dos identidades: un nmero de suscriptor conocido entre los suscriptores
(que se encuentra en el directorio telefnico) y una identidad externa usada por el personal de
mantenimiento del sistema.
Se entiende que los aparatos asociados a cada suscriptor reconocen que cuando se descuelga el
auricular se est iniciando una nueva llamada o se est respondiendo a una llamada.
Todos los dispositivos tiene una identidad externa.
Cada ruta tiene una identidad nica.

Es posible separar el sistema en 3 grandes componentes:


el manejo de las llamadas,
la operacin y mantenimiento del sistema, y
la generacin de indicadores.
Manejo de Llamadas
En el manejo de llamadas se pueden distinguir los casos a seguir.
Llamada entre lneas de suscriptores A y B: Cuando un suscriptor A levanta el auricular de su aparato,
el sistema Telecom realiza las siguientes acciones. En primer lugar se verifica la categora del suscriptor para ver si se le permite hacer llamadas. Si es as, el sistema marca al suscriptor como ocupado para
llamadas entrantes y le entrega tono de marcar. El tono de marcar indica que el sistema est listo para
recibir dgitos. El tono de marcar se desconecta cuando el primer dgito se recibe. Despus de ingresar
todos los dgitos, el suscriptor A ser conectado al suscriptor B.
Si el suscriptor B est ocupado, el sistema le retorna un tono de ocupado. Si el suscriptor B est
desocupado y su categora le permite recibir llamadas, ser marcado como ocupado y los suscriptores A
16

y B sern conectados. Cuando la conexin es realizada, el suscriptor B tendr una seal de llamada y el
suscriptor A recibir el tono de llamando. Ambas seales sern interrumpidas cuando el suscriptor B
responda. En una llamada normal, los dos suscriptores hablan algn tiempo antes de desconectarse. La
llamada ser desconectada cuando ambos suscriptores hayan colgado. En ese momento ambos suscriptores son marcados como desocupados y son desconectados.
Si uno de los participantes cuelga, la llamada se mantiene si el participante que colg levanta el auricular nuevamente. El suscriptor A puede concluir la llamada en cualquier momento durante el inicio
de la llamada y antes que el suscriptor B levante su auricular.
Llamada entre lneas de suscriptor A y de salida: Este caso es similar al de la llamada entre lneas de
suscriptores A y B, pero con algunas excepciones. La direccin de la llamada ser a una lnea de salida.
Esta se escoger de entre las lneas desocupadas de la ruta entre este sistema de conmutacin y el otro
sistema. La lnea ser marcada como ocupada durante la llamada de la misma forma que la lnea del
suscriptor B en el caso anterior. El sistema no necesita verificar la categora de la lnea de salida porque
a todas les es permitido recibir llamadas.
Llamada entre lneas de entrada y de suscriptor B: Este caso tambin es similar al de la llamada entre
lneas de suscriptores A y B, pero con excepciones. Esta funcin se activa cuando otro sistema de conmutacin inicia la comunicacin con el sistema Telecom. Todos los dgitos sern recibidos directamente y no es necesario verificar si la llamada puede originarse de esta lnea. De ah en adelante este caso
es idntico al de la llamada entre lneas de suscriptores A y B.
Llamada entre lneas de entrada y salida: Este caso es similar a los anteriores. La lnea donde se origina la llamada, en este sistema de conmutacin, es una lnea de entrada y la direccin de la llamada es
una lnea de salida.
Operacin y Mantenimiento
Cambios de suscripcin: Un operador puede conectar a un nuevo suscriptor al sistema o desconectar un
suscriptor existente. Cuando un nuevo suscriptor se conecta al sistema, el sistema es informado por el
operador del nmero telefnico, la identidad externa y la categora del suscriptor.
Cambios en la informacin de los dgitos: Un operador puede cambiar la informacin asociada a los
dgitos en el sistema. Esta informacin es usada en cada llamada para saber qu acciones tomar. Esta
informacin es estructurada como un rbol, donde cada nodo representa un dgito y un nodo hoja representa una direccin.
El resultado de un anlisis de dgitos se asocia a un nodo hoja. El resultado consiste en 3 componentes: el caso aplicable para el manejo de la llamada, una identidad de ruta externa (no aplicable a
llamadas a lneas de suscriptor B) y el largo esperado del nmero (dependiendo de la direccin de la
llamada). El largo esperado del nmero se usa para decidir cundo todos los dgitos de una llamada han
sido recibidos.
Conexin de dispositivos: Esta funcin se usa para conectar nuevos dispositivos y eliminar dispositivos
existentes en el sistema. Para cada dispositivo conectado, el sistema es informado de la identidad externa del dispositivo y la identidad externa de la ruta a la cual el dispositivo pertenece. La identidad de
ruta externa es usada fuera del sistema para comunicarse con el mismo.
Emisin de cuentas: Esta funcin permite generar una cuenta detallando todas las llamadas hechas en
las lneas de suscriptor A de cada conmutador del sistema. Se consigna el nmero marcado, la duracin
17

de la llamada, el horario en que fue realizada, la tarifa cobrada y los totales respectivos. Esta emisin
de cuentas es de periodicidad mensual, pero puede solicitarse en cualquier momento y para cualquier
periodo que se desee.
Generacin de Indicadores
El sistema Telecom requiere almacenar datos de su operacin para poder generar algunos indicadores sobre el desempeo del mismo. Estos indicadores son principalmente los siguientes:
tiempos promedios de espera (tiempo transcurrido entre el trmino del ingreso del nmero cuando
se hace una llamada y el retorno del tono de llamando u ocupado) en llamadas entre lneas de
suscriptores A y B, entre lneas de suscriptores A y se salida, entre lneas de entrada y suscriptores
B, y entre lneas de entrada y de salida
cantidad de llamadas y duracin promedio de las mismas, en horario de alto trfico (das hbiles de
8:00 a 20:00, y sbados de 8:00 a 12:00) y de bajo trfico (sbados de 12:00 a 24:00 y domingos y
feriados de 0:00 a 24:00), por cada dispositivo y por categora de dispositivo.
trfico promedio (llamadas simultneas) por conmutador y por hora
Estos indicadores sirven para determinar por ejemplo, los cuellos de botellas del sistema (pocas
lneas de salida o entrada en algunas rutas de alta demanda), nmero ptimo de suscriptores por conmutador, etc. Se busca en definitiva mejorar el servicio a los suscriptores sin que esto implique en aumentar las tarifas actualmente cobradas.

18) Problema del Sistema de Seguimiento de Tarjetas (SISTA) para modelamiento en grupo:
1 Antecedentes
Unibanco es un banco internacional con presencia en ms de 50 pases. Su objetivo es satisfacer
las necesidades crediticias y de inversin tanto de personas naturales como de empresas. Para lograr su
objetivo, esta institucin pone a disposicin de sus clientes diversos productos, tales como cuentas corrientes, depsitos a plazo, crditos de corto, mediano y largo plazo con diferentes modalidades de pago, fondos mutuos, compra de acciones, seguros y tarjetas de crdito. Tambin ofrece servicios, como
por ejemplo: informacin por canales formales y remotos, asesoras, pago automtico de cuentas, compra y venta de moneda extranjera y servicios financieros.
En particular, el negocio de tarjetas de crdito (TC) requiere de dos entidades fundamentales: el
emisor y el adquirente. El emisor es Unibanco, que otorga la TC y satisface las necesidades de financiamiento de los clientes. El adquirente es la institucin financiera que realiza el pago a los puntos de
ventas (locales comerciales). As entonces, los clientes consumen en locales comerciales; los locales
comerciales le cobran al adquirente; el adquirente le cobra a Unibanco; y Unibanco, a su vez, le cobra
al cliente.
Dado el alto volumen de transacciones que se realizan con TC (de 7 a 8 veces el volumen de
transacciones que un banco realiza normalmente) es que Unibanco requerira de una altsima capacidad
de procesamiento. Por esto, Unibanco ha dispuesto delegar este procesamiento a un tercer actor dentro
de este proceso: el procesador.

18

El procesador es quien mantiene los registros del parque de TC vigentes, genera los plsticos,
recibe los consumos desde el adquirente y centraliza e informa del total de consumos realizados por
cada cliente.
Dada esta dependencia entre Unibanco y el procesador, es que la relacin debe ser estrecha y
controlada en cada una de las funciones, tanto en la emisin de las TC como en la administracin de los
consumos realizados por los clientes.
Actualmente, Unibanco, el adquirente y el procesador poseen sistemas informatizados que cubren parcial e independientemente todo el proceso de la ruta de las TC, desde que son emitidas hasta
que son recibidas por los clientes y activadas para el consumo. Considerando el aumento sostenido de
este mercado, la forma actual de operar ha presentando las siguientes deficiencias:
prdida de la ruta de muchas TC,
inexistencia de un proceso de eliminacin de TC que ya no deban seguir la ruta,
volmenes inmanejables de TC en trnsito,
prdida de TC al interior de la red (por desconocimiento de su paradero),
cuellos de botella en la produccin, cuando intervenan estacionalidades en la venta 8por ejemplo en fiestas de fin de ao), y
sobrecarga de los sistemas automticos del procesador, dado que no existan criterios de limpieza de los registros.
2 Sistema de Informacin a Ser Modelado
El objetivo del Sistema de Seguimiento de Tarjetas (SISTA) es mantener el control del proceso
productivo, desde que se aprueba la generacin de una TC hasta que este producto est habilitado para
consumir.
El proceso involucra las siguientes reas:
aprobacin crediticia, desde donde se obtienen las TC que es necesario producir;
el rea que enva las solicitudes desde Unibanco al procesador;
el procesador, que crea los registros computacionales y fabrica las TC;
control de la produccin, que reside en Unibanco;
las empresas de distribucin de TC;
las reas internas que tienen contacto con el cliente (sucursales y fuerzas de venta con entrega directa);
control de entregas, que tambin reside en Unibanco; y
crditos, que autoriza la operacin crediticia y realiza la activacin de las TC (habilita las
TC para que puedan consumir).
Se requiere tener control sobre el proceso de produccin y distribucin de TC, en cada una de
sus etapas. Esto es importante porque una TC es un instrumento financiero nominativo del cliente, y
por lo tanto, ante un extravo o robo, ste puede ocasionar importantes prdidas econmicas a Unibanco.
Por lo anterior, se debe conocer el paradero exacto de cada una de las TC. No se pueden perder
y tampoco se pueden demorar excesivamente en cada una de las etapas involucradas, dado que en la
medida en que ms se demoran las TC en cada etapa, mayor es la probabilidad que pueda realizarse un
fraude con ellas.
19

Para poder realizar el proceso de control en cada etapa, es necesario que un rea de Unibanco se
haga responsable por tener y mantener el estado en el proceso productivo de las TC. Deber ser capaz
de conocer cualquier desviacin en el proceso y a su vez, deber tener la autoridad para exigir cualquier
cambio de ruta en dicho proceso. En este caso, el rea responsable ser Operaciones Tarjetas a cargo
de su Gerente, cuya misin es el de velar para que las TC aprobadas se produzcan y lleguen al cliente
dentro del menor tiempo posible, bajo las condiciones de seguridad necesaria.
En lo especfico SISTA debe servir de apoyo a:
el registro de las solicitudes de TC;
la recepcin de TC;
la entrega de TC al canal de distribucin;
la activacin de TC;
la recepcin de TC devueltas, las cuales deben destruirse y ser eliminadas de SISTA;
el registro de las causales del rechazo (la causales ms comunes son: el cliente no la solicit,
la tasa de inters es muy alta, la comisin cobrada es muy alta o la TC est mal emitida);
la exigencia al canal de distribucin, de rendicin de entrega de aquellas TC que an no han
sido activadas ni devueltas en un plazo de 45 das desde que fueron entregadas al canal; y
la generacin de un informe mensual de las TC rechazadas, devueltas y activadas.
Aparte del apoyo operativo que debe otorgar SISTA, se espera que deba mantener un proceso
de produccin de acuerdo a los estndares de rapidez en la entrega acorde con la competencia, y a la
vez, permita implementar mejoras para poder disminuir los tiempos en la entrega, sin aumentar las
condiciones de riesgo.
SISTA debe permitir conocer el comportamiento global del proceso para poder determinar en
qu puntos se pueden obtener mejoras importantes y cules son los nuevos comportamientos ante un
cambio en el proceso productivo. Esto significa que SISTA debe ser capaz de permitir el control sobre
el proceso global, indicando las excepciones, permitir la fijacin de estndares de los conceptos que
mida y, en general, servir de apoyo en el corto plazo para poder determinar cules son las desviaciones que se presenten, y a la vez, de apoyo en el largo plazo para poder encontrar cules son las
etapas dentro del proceso que conviene modificar en la bsqueda de mejoras.
Los conceptos a medir, que indicarn fundamentalmente el comportamiento del sistema, son:
1) Tiempo de ciclo: Que es el tiempo que transcurre para que una solicitud de TC se convierta en
una TC utilizable por el cliente.
2) Defectos: Que es la cantidad de TC que no han podido ser entregadas a los clientes, y por ende
no se han podido convertir en TC entregadas a los clientes. No se considerar como defecto
aquellas TC que el cliente ha rechazado, dado que es un defecto del proceso de ventas y no del
proceso productivo. Sin embargo, este concepto se entender como un concepto separado que
se entregar a las reas de venta para que puedan realizar control de calidad al mencionado proceso.
Las variables de tiempo de ciclo y de defectos son claves para la gestin de todo el proceso de
seguimiento, porque mientras la primera mide la eficiencia cul es la rapidez con la que se cumple el
objetivo, la segunda mide inversamente la eficacia el nmero de oportunidades en las cuales el
objetivo definitivamente no se cumple.
20

El tiempo de ciclo debe ser medido para un conjunto de TC. Un valor promedio es adecuado,
sin embargo, puede ser insuficiente en el caso en que la desviacin sea grande. Por lo tanto, es til poder elaborar y mostrar un histograma para aquellas TC que ya han sido activadas y que fueron creadas a
contar de la fecha que se indique.
La variable de defectos es complementaria a la anterior. Esto se debe a que un proceso debe tener una cantidad de errores considerada normal. A diferencia de la medida anterior, donde cada una de
las ocurrencias es la entrega de una TC, la cuantificacin de los defectos corresponde al nmero de das
de proceso en que la TC ha permanecido en el canal de distribucin (por sobre un lmite inferior establecido arbitrariamente) y que tambin fueron creadas a contar de la fecha que se indique. Lo ideal es
que se pueda permitir variar el lmite inferior.
En consecuencia, esta ltima variable servir para poder buscar dnde se producen los errores
que generan los defectos y cualquier contribucin en la disminucin del valor de la variable incidir en
el xito del negocio y por lo tanto en el aumento de la satisfaccin de los clientes. Por otra parte, servir
para evaluar objetivamente los cambios que se realicen buscando una disminucin de los tiempos de
ciclo, pues si un cambio realmente recorta estos tiempos, puede incidir en un aumento en el nmero de
errores y por lo tanto, ser un cambio conveniente a primera vista, pero contraproducente a nivel global.

19) Problema del Sistema de ECODepsitos para modelamiento en grupo:


1 Antecedentes
La empresa ECODepsitos de dedica al almacenaje de productos qumicos peligrosos. Comercializa ms de 60 productos a grandes empresas, principalmente de la minera y qumicas en general.
Posee depsitos habilitados en distintos lugares del pas. Cada depsito posee galpones especialmente
acondicionados para almacenar este tipo de productos.
Conciente de lo importante que es la conservacin del medioambiente, todos los depsitos de
ECODepsitos operan de acuerdo a las normas medioambientales nacionales, que regulan especficamente el almacenamiento y transporte de productos qumicos que daan el medio ambiente. Adems,
es supervigilado por la CONAMA (COmisin NAcional del Medio Ambiente) y en particular por la
COREMA (COmisin REgional del Medio Ambiente) de la regin donde se encuentre localizado cada
depsito.
A seguir se expone la situacin de operacin de un depsito menor de ECODepsitos, llamado
Armona II. Este depsito ser utilizado como piloto para un sistema genrico de apoyo a las operaciones y a la gestin, que posteriormente se implementar en los restantes depsitos del pas.
2 Sistema de Informacin a Ser Modelado
En el depsito Armona II, ECODepsitos est autorizada slo a almacenar tambores de qumicos clasificados por tipo de peligro 1, 2 y 3 (en los otros depsitos de almacenan adems qumicos de
los tipos 5, 6, 8 y 9).

21

Los tambores son almacenados en 8 galpones (otros depsitos tienen hasta 21 galpones). En las
mismas instalaciones tambin existen edificios para el personal tcnico y administrativo. Cada galpn
est autorizado para almacenar un nmero mximo de tambores (todos del mismo volumen). Adems,
la normativa especifica que los tipos de qumico 1 y 2 no pueden transportarse juntos, ni almacenarse
juntos en un mismo galpn; sin embargo el tipo 3 puede almacenarse y transportarse con los tipos 1 y
2. Si cualquiera de esas normativas es violada, la COREMA, a travs de sus fiscales, clausura el depsito en cuestin, clasificndolo como inseguro y, eventualmente, puede tomar medidas de emergencia junto a bomberos y su brigada especializada.
El sistema informtico a ser modelado para la operacin y control del depsito Armona II nunca debe permitir que el depsito llegue a estar inseguro.
A la administracin de ECODepsitos le interesa no tener problemas con los trabajadores, ni
con las autoridades locales (principalmente municipales), ni con el COREMA. Por esta razn, se ha
establecido que el gerente del depsito debe ser capaz de monitorear el estado del depsito y poder
verificar si el mismo est en un estado vulnerable por medio de este sistema. Para esto, el gerente debe
poder consultar el stock de cualquier qumico o tipo de tambor almacenado en los galpones. Para la
vulnerabilidad, la normativa establece que un depsito es vulnerable si cualquier par de galpones colindantes contienen el nmero mximo permitido de tambores, independiente de los tipos de qumicos.
Arbitrariamente, se ha definido el indicador de vulnerabilidad para cada par de galpones colindantes i, j
de la siguiente manera:
stock total galpn i
stock total galpn j
Vulnerabilidad = Promedio
,
n mx tambores galpn i n mx tambores galpn

La operacin del depsito puede dividirse en los procedimientos de recepcin y entrega de tambores.
Cuando un camin cargado de tambores llega a la rampa de carga / descarga, el funcionario de
rampa ingresa el manifiesto de carga y verifica los tambores individualmente. A cada tambor verificado
se le asigna un identificador. Una vez que todos los tambores han sido verificados e identificados, el
sistema debe informar al funcionario cualquier discrepancia entre la carga verificada y el manifiesto.
Seguidamente, el sistema debe emitir una lista de asignacin de los tambores recin llegados a los galpones del depsito, donde se indica exactamente dnde se debe almacenar cada tambor. Eventualmente, se le puede notificar al funcionario si algn o algunos tambores deben devolverse al camin debido
a falta de espacio de almacenamiento.
Adicionalmente, si el camin transportaba combinadamente tambores de los tipos 1 y 2 en una
misma carga, el sistema le avisa al funcionario de la inconveniencia de transportarlos juntos. La primera vez que esto ocurre con un transportista se le recibe la carga, pero se le indica que no se aceptarn
futuras cargas con esta combinacin.
Para la retirada de tambores, el funcionario de rampa ingresa una solicitud de manifiesto de carga, indicando el nmero y el producto qumico de los tambores requeridos. El sistema emite entonces
una lista que identifica los tambores que deben ser recuperados desde los galpones. Se utiliza siempre
una poltica FIFO (First In First Out) de entrega. Eventualmente, el sistema puede avisar de la inexis-

22

tencia de tambores de algn qumico, quedando incompleta parcial o totalmente la entrega solicitada.
Finalmente, se emite un manifiesto de carga efectiva para el funcionario.
Debido a que slo hay una rampa de carga / descarga, sta debe estar vaca antes de que una
recepcin o entrega comience. Es responsabilidad del funcionario notificar al sistema cundo la rampa
est vaca.
El gerente adems, debe ser informado por el sistema sobre el ndice de rotacin de los tambores de cada tipo, que se define como el cuociente de las salidas sobre la suma del stock inicial ms las
entradas durante un periodo. Asimismo, el gerente debe usar como una medida de desempeo del depsito, el porcentaje de tambores rechazados por mes y por tipo; y como medida del nivel de servicio,
el total de entregas totalmente satisfechas sobre el total de entregas solicitadas en el periodo.

20) Problema del Sistema de Park-o-Meter para modelamiento en grupo:


1 Antecedentes
La empresa Park-o-Meter Ltda. (PoM) fue recientemente constituida para atender algunas concesiones municipales ofrecidas en las principales ciudades del pas. Particularmente en varios estacionamientos construidos y calles de Antofagasta, La Serena, Coquimbo, Via del Mar, Valparaso y Concepcin.
La empresa cancela un valor fijo a la municipalidad por sector o por estacionamiento construido
en concesin, para un periodo contratado. Dependiendo del sector, el precio puede ser diferente, por
ejemplo, los sectores ms cntricos son ms caros. Sin embargo, el contrato de concesin establece un
precio final nico del estacionamiento por tiempo base indivisible para todos los sectores. As por
ejemplo, los 30 minutos cuestan lo mismo en el centro como en las calles alejadas del centro.

2 Sistema de Informacin a Ser Modelado


PoM ya adquiri un software en el extranjero para
el control de los sistemas automatizados en los estacionamientos construidos, y requiere ahora un sistema que
apoye la administracin de las concesiones en las calles.
Las calles son atendidas por vendedores sectorizados, quienes cobran el precio nico a cada usuario de un
estacionamiento por tiempo base indivisible. Por contrato
con la Municipalidad, cada vendedor debe emitir al usuario del estacionamiento un recibo numerado cuyo formato
es el de la figura al lado.
Los sectores concesionados son divididos en calles
o cuadras a partir de la numeracin correspondiente y la
indicacin de orientacin. As por ejemplo, en la figura,
Yungay S (2900) indica la calle Yungay lado sur con numeracin a partir del 2900 donde se ubica la Casa Central
23

de la UCV. Cada cuadra tiene un vendedor asignado en diferentes horarios. El sistema deber llevar un
registro detallado de los vendedores, las cuadras asignadas y los horarios respectivos, as como permitir
la programacin de vendedores y los reemplazos necesarios. Adems, para evitar vicios, se reprograma
a los vendedores de tal manera que no permanezcan ms de 3 meses en una misma cuadra de un sector.
Antes de iniciar su horario de trabajo, cada vendedor debe retirar un monto de dinero para efectos de vuelto caja chica y talonarios de recibos debidamente registrados. Al trmino de su horario de
trabajo, cada vendedor debe entregar a la central de PoM el monto de la caja chica y el resto de los talonarios de recibos. En PoM se registran los nmeros de los recibos vlidamente emitidos, conjuntamente con la patente del vehculo. Cada vendedor cancela el 93% del valor a pblico del tiempo base
indivisible por cada recibo emitido. El 7% restante corresponde a la comisin del vendedor 3.
El sistema debe revisar peridicamente 4 estos registros identificando usuarios frecuentes de
sectores y/o cuadras. Dependiendo de la frecuencia con que un determinado vehculo utiliza una cuadra
o sector, se le puede ofrecer al propietario 5 planes de estacionamiento que pueden cubrir de 1 a 12 meses. Existen 4 planes normales diferentes segn el rea de cobertura en la que el vehculo puede estacionarse:

Plan Cuadra: slo en la cuadra indicada;


Plan Subsector: en un conjunto de cuadras siempre dentro de un sector;
Plan Sector: en toda el rea de un sector; y
Plan Total: todos los sectores concesionados.

En estos planes, el conductor paga un valor fijo mensual y se le emite un adhesivo que debe ser
colocado en un lugar visible del parabrisas delantero. En este adhesivo constan los siguientes datos:
tipo de plan, descripcin del rea de cobertura, validez del plan y patente del vehculo.
Los vendedores deben permitir el libre estacionamiento de los vehculos con planes contratados
en sus reas de cobertura. PoM ofrece al vendedor un valor fijo mensual proporcional al tipo de plan
contratado para el vehculo y al horario atendido por el vendedor.
El sistema debe permitir generar indicadores como la tasa de utilizacin mensual de cada cuadra
y sector, para as determinar cules son las cuadras o sectores menos vendidos y ofrecer planes de desplazamiento ms econmicos para vehculos que ocupen cuadras o sectores ms vendidos. As por
ejemplo, si un vehculo se estaciona con relativa frecuencia en la cuadra A de un sector, se le puede
ofrecer un plan ms econmico que el de la cuadra A, para que se estacione en una cuadra B, cercana a
la A, cuya utilizacin es menor. Los planes de desplazamiento se ofrecen a vehculos con o sin planes
normales.
Los descuentos de los planes de desplazamiento en relacin a los planes normales se calculan
tub tuo
sobre la base del factor
*100%, donde tub es la tasa de utilizacin mensual del sector o cuatub
dra base y tuo es la tasa de utilizacin mensual del sector o cuadra ofrecida.
3

Los vendedores, adems, perciben un salario fijo. Sin embargo, esto cae fuera del mbito del sistema a disear.
Generalmente a cada 6 meses.
5
Siempre y cuando el vehculo est registrado en la Municipalidad de la concesin, dado que es sta la que proporciona los
datos sobre los propietarios de los vehculos.
4

24

21) Problema del Sistema de Control de Seguridad de Acceso (SiCSA) para modelamiento en grupo:
1 Antecedentes
Como es de conocimiento general, la Escuela de Ingeniera Industrial est pronta a mudarse al
nuevo edificio IBC de la UCV. El espacio se divide en 3 pisos (4 al 6) con un rea total de 2700 m2 y
un rea til de 1800 m2. El edificio en s se divide en 5 reas: una de investigacin y asistencia tcnica,
una de laboratorios, una administrativa, una de salas de clase y un rea central con dos alas de oficinas
para profesores hora y de jornada completa.
El lugar debe acomodar unas 500 personas diarias: la mayora estudiantes, pero tambin profesores, investigadores, funcionarios y empleados tcnicos, como tambin numerosos visitantes.
Sabiendo de la desaparicin de varios bienes de la escuela (computadores y partes) y personales
(documentos, libros, carteras, calculadoras, etc.), se decidi restringir el acceso a las diferentes reas,
salas y oficinas usando puertas automticas. Para esto se requerir un sistema denominado SiCSA (Sistema de Control de Seguridad de Acceso) para controlar adecuadamente el acceso a las reas del edificio.
2 Sistema de Informacin a Ser Modelado
El sistema SiCSA debe funcionar de la siguiente manera.
La apertura de cada puerta es controlada por un lector de una tarjeta de identificacin (tipo
cdigo de barras) que deben ser portadas por las personas. Estas tarjetas de identificacin se entregan a
las personas que necesitan acceso a las reas restringidas para realizar sus tareas.
Los derechos de acceso son distribuidos entre grupos de personas y grupos de puertas. Cada
persona y cada puerta deben pertenecer siempre a un grupo, aunque slo sea el nico miembro de ese
grupo.
Un grupo de puertas puede consistir en puertas distribuidas a travs de todo el edificio, pero
desde el punto de vista del control de acceso, slo interesa el concepto de grupo de puertas (las rutas y
movimientos al interior del edificio no se controlan). Sin embargo, una puerta dada no puede ser
miembro de ms de un grupo de puertas. Por otro lado, una persona dada puede ser miembro de varios
grupos, para tener los derechos de acceso correspondiente a la combinacin de los de todos los grupos a
los cuales pertenece.
Los derechos de acceso se definen para cada grupo de personas, describiendo el(los) grupo(s)
de puertas accesibles y los horarios permitidos para dichos accesos. Los derechos se describen en un
calendario anual sobre la base de una semana. Dado que habr pocos cambios de los derechos en el
tiempo, el calendario puede definirse usando semanas tpicas que describen una configuracin fija de
derechos. El supervisor puede crear tantas semanas tpicas como desee y todos los cambios posteriores
sern vlidos para los calendarios que usen estas semanas. Sin embargo, puede hacerse modificaciones
directamente en el calendario (por ejemplo para incluir feriados), las cuales no se ven afectadas por el
cambio en la semana tpica.

25

La siguiente tabla muestra una semana tpica. Las reas grises corresponden a horarios durante
los cuales el acceso no est autorizado.
Lunes

Martes

Mircoles

Jueves

Viernes

Sbado

Domingo

00-01
01-02
...
06-07
07-08
08-09
...
21-22
22-23
23-24

SiCSA debe operar tan autnomamente como sea posible, no obstante se requiere un supervisor
para la configuracin inicial y la actualizacin de datos de los grupos de puertas y de personas. Adems
se requiere un guardia, quien tiene un monitor de control y es informado de todo intento fallido de entrada. Las alarmas son transmitidas con una pequea demora ya que la actualizacin de datos en el monitor de control es hecha una vez por minuto.
Adems, SiCSA debe permitir obtener, para cualquier periodo que se solicite (desde un da hasta un ao), informacin sobre los intentos de ingreso tanto fallidos como exitosos de la siguiente forma:
1. Nmero total de intentos fallidos/exitosos e indicador de intentos fallidos/exitosos totales dividido por el nmero de puertas totales accesadas fallidamente/exitosamente.
2. Distribucin de intentos fallidos por causa (no identificado, no autorizado, falla lector, falla sistema, otros).
3. Distribucin de intentos fallidos/exitosos por grupo de puertas y por puerta, ordenadas de menor
a mayor grficamente.
4. Distribucin de intentos fallidos/exitosos por grupo de personas y por persona, ordenadas de
menor a mayor grficamente.
5. Histrico comparativo con iguales periodos hacia atrs e igual periodo de las semanas, meses o
aos anteriores, segn corresponda, para cualquiera de los 3 tipos de informacin anteriores.
A modo de ejemplo, para la informacin del punto 1, SiCSA debiera indicar para el periodo de
Mayo de 2001 un total de 985 intentos fallidos y 21897 intentos exitosos, con indicadores de 123,1
intentos fallidos (985/8 puertas) y 405,5 intentos exitosos (21897/54 puertas). Para el histrico comparativo del punto 5, se debe mostrar los valores histricos de los meses de Abril de 2001 hacia atrs, y
del mismo mes de Mayo de los aos 2000, 1999, etc.

26

22) Problema del Sistema RedAmiga para modelamiento en grupo:


1 Antecedentes
Un empresario extranjero de vacaciones en Chile, entr a una farmacia de una conocida cadena
nacional. Dado que l mismo posee una pequea cadena en Ecuador, quiso curiosear para ver si encontraba alguna idea til para su propio negocio. Sin proponrselo dio con un folleto de una promocin
que le encant.
Al regresar al Ecuador, entreg el folleto a uno de sus mejores ingenieros pidindole que estudiara la idea y que evaluara la posibilidad tcnica de implementarla en su cadena de farmacias.
Algunos das despus, el ingeniero confirm que era posible construir un sistema semejante, pero que debera ser modelado previamente antes de pensar construir nada. El empresario autoriz entonces el proyecto para el desarrollo del sistema bautizado como RedAmiga.
2 Sistema de Informacin a Ser Modelado
En la pgina siguiente se reproduce el folleto promocional utilizado como base para RedAmiga.
Para el caso del Ecuador, se definieron los siguientes valores:
Se abona 1 punto a la cuenta de cliente por cada S/.4000 (sucres ecuatorianos) que compre l
mismo y 1 punto a la cuenta del cliente por cada S/.20000 que compre cada uno de sus invitados.
Se abona 1 punto a la cuenta del cliente por cada S/.2000 que compre l mismo de Productos
Oro y 1 punto a la cuenta del cliente por cada S/.10000 que compre cada uno de sus invitados
de Productos Oro.
Se descuenta S/.40 por cada punto que tenga el cliente en las compras que realice, un vez haya
completado el mnimo de 500 puntos de canje.
Los puntos tienen vencimiento de 1 ao a partir del momento en que la cuenta se crea con su
primer abono, o cuando despus de haber sido utilizados todos sus puntos, recibe un abono.
Finalmente, el ingeniero propuso que el sistema de RedAmiga generara al menos 2 indicadores
iniciales que den cuenta del desempeo de la promocin. Estos indicadores son:
Rotacin de puntos: dado un periodo cualquiera, cuntos puntos existan en las cuentas al inicio
del periodo, cuntos puntos se abonaron y cuntos fueron descontados durante el periodo, para
todos los clientes de RedAmiga.
Ranking de islas de clientes (una isla es un conjunto de clientes e/o invitados aislados del resto): para un momento dado, indicar las islas de clientes ordenadamente segn el total de puntos
en todas sus cuentas.

27

28

23) [PARCIALMENTE RESUELTO] Problema del sistema VolBanco para modelamiento en grupo:
VolBanco es una ONG (Organizacin No-Gubernamental) sin fines de lucro que ofrece voluntarios para personas y grupos que requieran ayuda. Su misin es promover la ciudadana y un sentido
de comunidad involucrando personas en actividades voluntarias en su propia regin. Para esto, VolBanco mantiene una lista de oportunidades y una lista voluntarios y busca asignar voluntarios a las mejores oportunidades disponibles.
Parte de la filosofa de VolBanco es que todos tienen habilidades para ofrecer y necesidades por
satisfacer. Por lo anterior, se incentiva tambin a los voluntarios para que registren sus necesidades y a
los receptores de ayuda para que ofrezcan sus propias habilidades. Por ejemplo, un caso real es el de
Pedro Durn que se ofreci para pintar y decorar. Para l se encontr una escuela bsica local que necesitaba repintarse. Por su parte, un grupo de nios de la escuela se ofreci para montar un show artstico en un hogar de ancianos. Uno de los ancianos del hogar, el Sr. Michelis, ofreci la posibilidad a alguien para conversar en italiano. Pedro Durn tom su ofrecimiento para aprender italiano antes de
viajar de vacaciones a Italia.
El nombre VolBanco parti de la idea de que las personas pueden depositar el tiempo que
ofrecen dar, como tambin las habilidades que poseen. La informacin sobre VolBanco est disponible
en distintos medios tales como radios locales, publicidad en televisin e Internet. VolBanco se ha asociado con organizaciones locales de voluntarios (OLV) para proponer trabajos voluntarios. Tambin
sirven como contactos locales para voluntarios que deseen ofrecerse.
Los voluntarios pueden registrar las habilidades que ofrecen a VolBanco por telfono a un organizador voluntario (OV), en persona a travs de una OLV o llenando un formulario en una pgina
web. Una vez que se registran, deben depositar el tiempo en el VolBanco por el mismo medio. Si el
voluntario se registra por medio de una OLV, sta debe hacer llegar la informacin por escrito a VolBanco, donde se registra por un OV, del mismo modo como si el voluntario hubiera contactado a VolBanco directamente por telfono.
Tanto las OLV como individuos (incluyendo a voluntarios) pueden registrar sus necesidades de
ayuda contactando un OV. Este OV debe intentar encontrar personas que ofrezcan su tiempo en las
oportunidades buscadas. Esto puede ocurrir de 2 maneras: un nuevo voluntario puede satisfacer una
oportunidad, o una nueva oportunidad puede ser satisfecha por un conjunto de voluntarios. Esta
bsqueda se hace en reas geogrficas crecientes de 50, 100, 200 y 400 km a la redonda, y considerando las habilidades necesarias.
Una vez que se le han encontrado oportunidades a los voluntarios, se les notifica los detalles y
si se interesan, sus propios detalles son entregados por el OV a la OLV o individuo que requiere la
ayuda. Se les deja constancia a los voluntarios que esto no significa que la ayuda ser automticamente
aceptada. Para algunos tipos de trabajo, tales como aquellos relacionados con nios, se requieren algunos procedimientos adicionales e incluso verificaciones con la polica. Estas son responsabilidades de
la OLV o individuo que requiere la ayuda.
VolBanco est un proceso de definicin de un sistema informtico que soporte el registro y
bsqueda de voluntarios y de oportunidades y permita notificar a los participantes. El sistema informtico debe permitir encontrar voluntarios para las oportunidades y oportunidades para los voluntarios y

29

deber conectarse con el servidor web de VolBanco 6. Las OLV miembros debern ser notificadas cada
vez que se encuentre un voluntario para una oportunidad que hayan registrado. Esto ser hecho por fax
o e-mail. Los voluntarios sern notificados por carta cuando se les encuentre una oportunidad.
De hecho, esta misma necesidad de desarrollo del sistema informtico se plante dentro de
VolBanco como una oportunidad en la bsqueda de profesionales voluntarios que pudieran modelar,
disear y construir el sistema. Se entiende como parte de este trabajo el definir de qu forma se har la
bsqueda de voluntarios y de oportunidades para lograr juntarlos efectivamente en actividades de voluntariado.
Adicionalmente a todo el soporte para el registro de los voluntarios y sus depsitos de tiempo,
de las oportunidades de actividad voluntaria, y de los oferentes y receptores de esta actividad voluntaria
conjuntamente con sus resultados; el sistema debe permitir genera informes estadsticos que permitan
conocer:
el nmero de voluntarios, sus formas de registro, clasificados y totales;
las oportunidades totales y clasificados;
la variacin y distribucin del tiempo depositado; y
el tiempo total, clasificado e individual de permanencia de registros de voluntarios sin trabajar y de oportunidades sin atender.

24) Problema del Sistema SIEX-Com para modelamiento en grupo:


1 Antecedentes
La empresa X-Com es una gran empresa multinacional del sector de tecnologas de la informacin y comunicaciones. Su liderazgo se ha reforzado en los ltimos aos por una filosofa de innovacin continua. En este sentido, X-Com le preocupa particularmente la gestin de su capital intelectual,
sobretodo en lo que se refiere a la incorporacin de personal nuevo.
El Sistema de Informacin de Entrenamiento de X-Com (SIEX-Com) es un sistema que pretende mejorar la eficiencia y la eficacia de la gestin de los cursos de entrenamiento de personal. En
trminos generales, debe apoyar la gestin de:
los participantes programados para los cursos,
los participantes de ltima hora,
informacin para los expositores de los cursos, e
informacin para el sistema del Departamento de Personal.
2 Sistema de Informacin a Ser Modelado
Cada 2 o 3er da hbil del mes, X-Com provee cursos introductorios de entrenamiento a los
empleados que han ingresado a la empresa el mes anterior. A estos empleados se les denomina joiners.
En este curso, un miembro del Grupo Internacional y varios miembros del Staff Nacional son expositores que introducen a los joiners en la filosofa de innovacin continua y los procesos operacionales de
X-Com. Generalmente los joiners conforman de 4 a 9 grupos pequeos, que funcionan como cursos

El servidor web es un sistema separado, que actualiza una base de datos de voluntarios.

30

paralelos. SIEX-Com apoya al coordinador de los cursos y al resto del personal del Departamento de
Entrenamiento para preparar y organizar los cursos.
El coordinador de los cursos usa el SIEX-Com para identificar a los joiners registrados en el
SIPeX-Com (Sistema de Informacin de Personal) por medio de una conexin en lnea. De acuerdo a
una solicitud, SIEX-Com asigna a los joiners a los diferentes grupos para los 2 das, evitando tanto
cuanto posible colocar juntos en un grupo a joiners de una misma oficina el 1er da; y asegurando que
los grupos del 2 da tengan joiners que no estuvieron juntos el 1er da. De esta manera, cada participante conoce a la mayor cantidad posible de personas de diferentes oficinas.
A pedido del coordinador, el SIEX-Com imprime las listas de participantes por da y por sala e
incluye el nmero total de personas en cada lista. Estas listas se entregan a los expositores. SIEX-Com
tambin imprime identificaciones que se preparan con anticipacin al inicio del curso.
Antes de que el curso comience, todas las identificaciones junto con el material del curso son
expuestos en una mesa. Entre las 8:00 y 8:30 del primer da, los joiners van llegando y rescatan sus
identificaciones y el material respectivo. Puede suceder que algunas personas que lleguen no aparezcan
en las listas, ya que corresponden joiners no registrados en el SIPeX-Com cuando los datos fueron consultados. Estas personas son registradas, ingresando sus datos al SIEX-Com e imprimindoseles su
identificacin. SIEX-Com tambin asigna a estos nuevos participantes a algn grupo.
En cualquier momento durante el curso, el expositor puede requerir al coordinador una lista
actualizada de los participantes de su curso.
El da siguiente al trmino del curso, todas las identificaciones restantes son usadas por la secretaria para registrar el ausentismo de joiners en el SIEX-Com. Estos datos son enviados en lnea para el
SIPeX-Com.
Finalmente, el coordinador recibe un informe sobre el entrenamiento del mes que indica el
nmero total de participantes, participantes de ltima hora y ausentes, y la distribucin de los grupos
por oficina y por da.

25) Problema del Sistema del Servicio MedDiata para modelamiento en grupo:
1 Antecedentes
El SERNAC (SERvicio NAcional del Consumidor) ha decidido establecer para el prximo ao,
un portal en Internet que aparte de entregar informacin general sobre el consumo, debe servir para
resolver y dar a conocer los problemas que tengan los consumidores con respecto a servicios y productos ofrecidos por empresas o instituciones en Chile, amparados en la Ley de Proteccin al Consumidor.
El sitio web se denominar www.meddiata.cl y su nombre se configura a partir del concepto de
mediacin inmediata. La mediacin tiene que ver con el rol de mediar eficazmente cuando existan
discrepancias entre oferentes y demandantes, siempre y cuando estos ltimos sean personas naturales o
consumidores finales. Esta mediacin es hecha despus de que el consumidor ha agotado instancias
personales de reclamo y antes de que, eventualmente, el caso sea llevado a la justicia. La inmediatez se
relaciona con la eficiencia de esta mediacin en trminos de tiempo, con un compromiso de entregar
una respuesta cumpliendo el plazo prometido.
31

El servicio MedDiata (Mediacin inmeDiata), como ser conocido, busca la eficiencia, haciendo un buen uso de los recursos, lo que le significar una buena imagen con los consumidores. El director del proyecto para este servicio manifiesta que ...creemos que es perfectamente posible que un servicio pblico sea de buena calidad, utilizando las TI de manera racional, logrando una productividad
comparable con las empresas privadas, sin que esto signifique presupuestos excesivos. Nuestra excelencia operacional se convertir en una referencia obligada para otros servicios del pas.
Bajo esta concepcin, el servicio MedDiata se ha planteado utilizar los conceptos del Cuadro de
Mando Integral (CMI) definiendo perspectivas, objetivos e indicadores que den cuenta del desempeo
de la gestin del servicio, bajo la misin de mediacin eficaz e inmediatez.
2 Sistema de Informacin a Ser Modelado
El sistema de informacin a modelar deber sustentar el proceso de atencin de los casos de los
consumidores y generar un indicador por cada perspectiva del CMI.
El proceso propuesto de atencin de los casos a tratar por el servicio MedDiata puede sintetizarse de la siguiente forma:

7
8

El consumidor se contactar con el servicio, de preferencia va formulario web o e-mail 7, entregando los antecedentes del caso: datos del consumidor, producto/servicio, prestador, documentos involucrados, deficiencias, fechas, cronologa de hechos, posicin del prestador, posicin del
consumidor, y otros antecedentes que se estimen pertinentes.

Un recepcionista revisar los antecedentes, buscando entenderlo. Este recepcionista deber contactarse con el consumidor para confirmar la recepcin de su caso, describirle cmo entendi el
caso y solicitarle aclaraciones, la entrega de ms antecedentes o el envo de copias de documentos. El recepcionista determinar entonces si es posible aceptar el caso por el servicio MedDiata.
De no ser as deber exponer claramente al consumidor y a su supervisor el rechazo del caso. En
los casos aceptados, deber asignar un nombre de usuario y solicitar una contrasea al consumidor, si ste es nuevo para el servicio.

El recepcionista contactar a un ejecutivo en el rea principal del caso y lo registrar. Estas reas podran ser garantas, cambios, seguros, financiera, grandes tiendas, importadores, etc. Se
prev que exista una gran dinmica de crecimiento de las reas en funcin de los casos que lleguen y no siempre ser posible encontrar un ejecutivo con experiencia en casos similares. Una
vez asignado, el ejecutivo deber contactarse con el cliente pactando un plazo de solucin para
el caso, en funcin de su carga de trabajo (se espera que no supere los 30 das hbiles).

El ejecutivo del caso har un plan de tramitaciones con un presupuesto a partir de estndares
predefinidos. Este plan ser entregado al supervisor, quien lo aprobar o sugerir correcciones.

El ejecutivo publicar el plan aprobado y registrar los hitos en la ejecucin del plan, de tal manera que el consumidor puede consultarlo en lnea permanentemente 8. Las tramitaciones ms
comunes son la de contactar prestadores, consumidores, expertos, otros ejecutivos, buscar informacin tcnica, etc.

En casos especiales, como los consumidores de la 3 edad, se aceptarn contactos va fax o telfono.
Este monitoreo podr hacerse telefnicamente para los consumidores de la 3 edad.

32

El ejecutivo deber dar por concluido el caso comunicndoselo al consumidor y entregando el


resultado: sin solucin por no haber oferente que responda; resuelto sin contacto con el consumidor (est inubicable); y resuelto con contacto confirmado con el consumidor. El resultado
podr ser favorable o desfavorable para el consumidor. En el acto de trmino del caso, el ejecutivo debe ofrecer una encuesta web o telefnica sobre la satisfaccin del consumidor con el servicio.

Finalmente, el ejecutivo clasificar el caso con 3 o ms palabras claves y lo publicar como un


resumen en el portal de MedDiata, para que quede disponible para el pblico en general.

Los siguientes indicadores bsicos se han propuesto para el CMI del servicio, todos para un periodo dado:
En la perspectiva del consumidor: grado de satisfaccin promedio (nota 1 a 7) con el servicio,
medida por medio de la encuesta, en trminos de calidad y tiempo.
En la perspectiva financiera: presupuesto promedio por caso.
En la perspectiva de aprendizaje organizacional: distribucin de casos por reas y por ejecutivos
En la perspectiva de procesos internos: tiempo promedio real de resolucin de casos.

26) [PARCIALMENTE RESUELTO] Problema del Sistema de Ventas On-Line www.marraqueta.cl


para modelamiento en grupo:
1 Antecedentes
Un grupo de ingenieros comerciales, industriales e informticos recin egresados (IIC Ltda.) dijeron basta! a los vendedores extranjeros va Internet y decidieron instalar su propio sitio denominado
www.marraqueta.cl (an no registrado), para vender los tipos de productos que ms se transan electrnicamente: libros, CDs y videos, todos de procedencia legal y preferentemente de produccin nacional. La idea es que en el mediano plazo pueda diversificarse la oferta y entregar ms productos nacionales. Los socios decidieron darle un fuerte distintivo nacional al sitio y a los productos ofrecidos, pero
con un servicio world class. Consideran que un porcentaje significativo de los clientes debieran ser
extranjeros o chilenos radicados en el exterior, los cuales estn acostumbrados a altos niveles de calidad en los servicios que contratan.
El nombre del sitio fue adoptado por ser la marraqueta (pan batido o francs) uno de los alimentos ms recordados y anhelados por los chilenos que viven en el exterior, y de mayor aceptacin por los
extranjeros que visitan el pas.
Los ingenieros de IIC aplicaron sus conocimientos y decidieron realizar un benchmarking para
copiar las buenas ideas de algunos de los grandes y exitosos del comercio electrnico. Amazon.com,
Borders.com, Barnes&Noble y Beyond.com fueron algunos de los sitios web cuidadosamente analizados para extraer principios que orientaran el diseo del similar chileno.
Los aspectos estticos nacionalistas fueron entregados a una pequea empresa de diseo grfico
computacional, cuyos socios eran conocidos de IIC.
El financiamiento pudo conseguirse con algunos ahorros, aportes mayores de algunos familiares
y una cuenta de publicidad para las pginas del sitio web. La inversin es relativamente pequea en
personal, local, equipamiento, software, servicios contratados de conexin a Internet, publicidad en
revistas especializadas y en buscadores de Internet y capital para inventario.

33

2 Sistema de Informacin a Ser Modelado


El sistema a ser modelado debe dar apoyo al servicio al cliente, para que ste pueda navegar
libremente recopilando informacin muy variada sobre los productos que desea comprar en el sitio
web, ofrecerle la opcin de poder adquirir los productos deseados y permitirle monitorear el estado de
avance de su pedido hasta su despacho. Adems, este sistema debe permitir obtener informacin sobre
el comportamiento global de los compradores para planificar las compras, campaas de descuentos,
oferta a los clientes y otros.
Los productos comercializados electrnicamente son videos (documentales, musicales, pelculas), CDs (de cualquier gnero musical) y libros (de cualquier gnero literario). Como se desea vender
en forma virtual, stos deben contar con la mayor cantidad de datos posibles para que el cliente pueda
decidir informadamente. Esto incluye una foto de la portada del video, CD o libro. La tabla 1 muestra
los datos bsicos para cada tipo de producto.

VIDEO

Tabla 1 Datos bsicos para cada tipo de producto.


CD
LIBRO

ttulo
director(es)
productor(es)
ao y lugar de publicacin
duracin
actores y/o narradores
idioma(s)
con/sin subttulos
color/blanco&negro
sistema de reproduccin
(Pal-N, Pal-M, NTSC)
N de serie
N de unidades
categora(s) a las que pertenece
resea de contenidos
observaciones

ttulo
artista(s) (o compositor(es) e
intrprete(s))
sello
N de catlogo
ao y lugar de la publicacin
idioma(s)
lista de pistas y duracin
individual
duracin total
formato digital (AAD, ADD,
DDD)
categora(s) a las que pertenece
N de unidades
observaciones

ttulo
autor(es) o editor(es)
editorial
ao y lugar de publicacin
ndice de contenidos
ISBN (International Standard
Book Number)
idioma(s)
edicin
reimpresin
categora(s) a las que pertenece
formato de encuadernacin
N de pginas
N de volmenes
observaciones

Es importante destacar que, dado lo cambiante del mercado de estos 3 tipos de productos, las
clasificaciones deben ser abiertas y con posibilidad de combinar sus categoras. As por ejemplo, un
CD de Inti Illimani puede ser clasificado como folclrico-andino y popular-vocal-romntico-bolero al
mismo tiempo, y si esto termina creando un gnero hbrido, el sistema deber permitir su inclusin posterior, como por ejemplo vanguardia-fusin-raz nativa.
Aprovechando las posibilidades que ofrece Internet, se desea implementar tambin la posibilidad de entregar sinopsis de los videos, extractos de pistas de los CD y trozos de los libros para que los
clientes tengan an ms informacin sobre el producto que desea comprar 9. Inicialmente, slo un porcentaje pequeo de los productos tendr esta opcin, pero a medida que el negocio crezca y se pueda
invertir en mayores capacidades de los servidores y de comunicacin, esto debera generalizarse.
Uno de los principios de diseo del servicio es entregar la posibilidad de crear una cuenta individual gratuita por cliente, donde consten sus datos personales, como nombre, correo electrnico, di9

El pago de derechos de autor no constituye un costo apreciable para esta modalidad de divulgacin de las obras.

34

reccin personal, direcciones de despacho, direcciones para regalos y formas de pago (cheque US$,
tarjeta de crdito o depsito en cuenta bancaria). Esta cuenta es personal y debe tener mecanismos de
seguridad como contrasea y encriptacin para el acceso y almacenamiento.
Gracias a la tecnologa web, es posible ofrecer al cliente la navegacin sobre los diferentes productos a la venta y que ste sea capaz de agregarlos a una cesta de compras. Alternativamente, el cliente puede almacenar productos en diferentes cestas bastando para ello que l las denomine distintamente. Los productos en estas cestas pueden ser posteriormente removidos o sus cantidades modificadas,
dentro del proceso de pasar a caja. La bsqueda se puede hacer por cualquiera de los datos asociados a
cada producto. Eso s, el cliente debe indicar cul es el tipo de producto buscado. Cada resultado de una
bsqueda le debe dar la posibilidad de ver otros productos relacionados (usando los vnculos de las
pginas) por director/productor/artista/autor. Por ejemplo, si el cliente busc un libro sobre Violeta
Parra, debera poder ver tambin los videos y los CDs que tengan relacin con ella.
En el proceso de pasar a caja, el cliente debe individualizarse, si es que no lo ha hecho previamente. Si es un cliente nuevo, se le deber ofrecer la posibilidad de crear una cuenta en este momento o
se le puede dar la opcin de ser cliente eventual, el cual slo entrega datos para hacer su compra sin
que se cree una cuenta individual. Con la cuenta individualizada, el cliente debe confirmar los datos
sobre la forma de pago, la direccin para el despacho y si corresponde a un regalo. Luego se le indica el
valor total de los productos y del flete correspondiente 10. Seguidamente, el cliente debe indicar si desea
se le despache todos los productos juntos o de acuerdo a la disponibilidad 11 (en este ltimo caso el flete
total es ms caro, porque cada vez se calcula el flete como si el despacho parcial fuera un pedido). El
pedido es numerado nicamente y se agrega al historial de pedidos del cliente registrado.
Los pedidos realizados durante un da son procesados el da hbil siguiente en la seccin Solicitud a Proveedores de IIC, donde son ordenados los pedidos a los proveedores correspondientes, si es
que los productos no se encuentran en bodega. En general, los niveles de stock son bajos, pero a travs
de convenios especiales con proveedores se logra bajar los costos de adquisicin con plazos de entrega
breves. Si el pedido es de acuerdo a disponibilidad, y la seccin de Finanzas da su autorizacin, los
productos son despachados al da hbil siguiente. Si el pedido es de despacho total, ste se almacena en
bodega en espera de completarse. Si el pedido no se completa en 60 das, ste es despachado y los restantes productos son cancelados 12. Los productos de disponibilidad desconocida pueden esperar hasta
120 das. En el momento del despacho del pedido, se informa a Finanzas sobre el mismo para hacer
efectivo el pago.
Usando su cuenta individual, el cliente debe poder revisar el estado de todos los pedidos realizados, incluyendo los que an estn en proceso. Si el cliente quiere, puede cancelar total o parcialmente
un pedido que no se encuentre an en bodega, es decir, los productos solicitados que an no hayan sido
recibidos de los proveedores pueden cancelarse. Lo cual obliga a definir claramente cul son las etapas
10

El flete se calcula en base a un valor fijo y un valor por tem, y bajo 2 modalidades: normal y expresa. Ambas modalidades tienen valores distintos dependiendo de las zonas: Zona nacional 1 = Regin Metropolitana; Zona nacional 2 = III, IV,
V, VI, VII, VIII y IX regiones; Zona nacional 3 = I, II, X, XI y XII; Zona nacional 4 = Chile insular occidental; Zona internacional 1 = Sudamrica; Zona internacional 2 = Centro y Norteamrica; Zona internacional 3 = Europa occidental y Africa; Zona internacional 4 = Medio Oriente y Europa Oriental; y Zona internacional 5 = Asia y Oceana.
11
La disponibilidad est dividida en 1-2 das, 7-10 das y 21-30 das. Algunos productos tienen disponibilidad desconocida,
porque son pedidos especialmente.
12
Si el proveedor no informa que el producto ha sido descontinuado, esto significa alterar la disponibilidad del producto al
plazo 21-30 das o desconocida, segn sea el caso.

35

por las que pasa cada producto, desde que es solicitado por el cliente hasta que le es despachado. Cada
avance de etapa debe ser actualizada por las secciones involucradas, de tal modo que se reflejen inmediatamente en el sitio web.
A los datos indicados de cada tipo de producto, el cliente registrado y el eventual puede agregar
comentarios clasificados en 3 categoras: como productor del video/CD o editor del libro, como director/artista del video/CD o autor del libro y como espectador/auditor/lector del producto. Estos comentarios, tanto positivos como negativos, enriquecen los productos con informacin para futuros compradores. En la modalidad espectador/auditor/lector debe entregarse adems una evaluacin en una escala de
1 a 10.
Con todos los datos disponibles de los pedidos hechos por los clientes, es posible generar informacin para los propios clientes como para la gestin del negocio. Inicialmente se puede entregar un
ranking de ventas, es decir, indicar para cada producto su posicin relativa en el volumen de ventas del
tipo de producto. Cada producto puede ir acompaado de esta informacin cuando presentado al cliente, como as tambin se le debe proporcionar navegacin sobre los top 100 ms vendidos de la lista de
videos, CDs y libros. Lo mismo ocurre con la evaluacin hecha por los clientes, que permite construir
un ranking de preferencias de los clientes, en base al promedio de las evaluaciones por producto. La
lista de los top 100 mejor evaluados por cada tipo tambin debe ser navegable. Asimismo, con el historial de pedidos es posible proporcionar informacin sobre productos que son comprados juntos ms
frecuentemente. Por ejemplo, un determinado cliente desea comprar un video sobre aves chilenas de
Sergio Nuo, y el sistema le puede sugerir un video Al Sur del Mundo de Francisco Gedda, un CD sobre canto de aves chilenas y libros de fotografas de naturaleza nativa, porque existen pedidos anteriores donde el video de Nuo se haba comprado con 1 o ms de estos otros productos.
La generacin de los rankings y los productos asociados, as como informacin sobre los volmenes de venta totales, por tipo de producto, por producto y por cliente, son muy tiles para dirigir
ofertas y descuentos para los clientes, negociar convenios con los proveedores de los distintos productos y con las empresas de courier y desarrollar, en general, estrategias para el negocio.

27) Problema del Sistema TripService para modelamiento en grupo:


1 Antecedentes
La introduccin de la marca tailandesa de vehculos Triptung ha requerido importantes inversiones de parte de la casa matriz y sus distribuidores en Chile. La idea es utilizar la experiencia en este
pas para alcanzar a toda Latinoamrica.
Consciente de que la calidad de los vehculos es competitiva internacionalmente, se ha decido
por una diferenciacin basada en el servicio postventa. Por esto, se quiere un sistema que apoye todo el
proceso de revisin y reparacin de vehculos en todos los servicios autorizados del pas. A este sistema se le ha denominado TripService.
2 Sistema de Informacin a Ser Modelado
El sistema a ser modelado debe soportar las actividades del taller a partir de una orden de trabajo emitida por un supervisor a la hora de recibir un vehculo de un cliente, hasta que el vehculo reparado es entregado conforme por el supervisor al cliente.

36

En el momento de generar la orden de trabajo, el supervisor debe verificar y registrar el estado


general del vehculo (ruedas, estanque, rayones, abollones, kilometraje, etc.), los datos del cliente y del
vehculo si alguno es nuevo al servicio, y constatar qu requiere el cliente. En general, las rdenes de
trabajo pueden ser revisiones cada 10.000 km reparaciones puntuales, o ambas. Las reparaciones peridicas estn sujetas a un plan de tareas predefinidas que son especficas a la revisin, es decir, la revisin de 10.000 km requiere tareas distintas que la de 20.000 30.000 km.
Una vez recibido el vehculo, el supervisor programa la orden de trabajo en el sistema TripService e indica al cliente una fecha/hora estimada de entrega del vehculo y un presupuesto preliminar de
acuerdo lo que le informa el sistema. Para esto, TripService asigna la orden dependiendo de la carga de
trabajo de cada unidad del taller, y entrega un tiempo y costo estimados para cada tarea, utilizando los
estndares definidos y agregndose a las listas de tareas de cada unidad de taller.
Cada responsable de unidad, revisa su lista y comienza atendiendo el vehculo correspondiente,
registrando la hora de inicio y los materiales requeridos. Caso necesite de algn repuesto, el responsable lo identifica y TripService automticamente lo consulta con el sistema TripPart, verificando la disponibilidad del repuesto. En caso de no contar con l, debe avisar al supervisor para que ste se contacte con el cliente a fin de estimarle un nuevo plazo de entrega. Si el repuesto est disponible, lo solicita a
TripService que coloca la orden directamente en TripPart; con esto el responsable ya puede pedir el
repuesto en el mesn correspondiente, donde ya estn en conocimiento de la solicitud.
Una vez que el responsable concluye su trabajo, ingresa la hora de trmino y el sistema calcula
automticamente las horas-hombre utilizadas y el costo de los repuestos (descargado de TripPart) y
materiales utilizados.
El supervisor de tiempo en tiempo (generalmente cada 1 hora) verifica el avance de la orden de
trabajo en cada vehculo. TripService le indica los atrasos que pudieran generarse y los costos acumulados hasta el momento. En el caso de que los tiempos utilizados superen en ms de 50% al estimado, o
que los costos acumulados superen en ms de 33% al presupuesto preliminar, TripService indica que se
debe contactar al cliente para explicar las modificaciones.
Adems, el sistema avisa cuando una orden de trabajo ha sido completada. Con esto, el supervisor lleva el vehculo correspondiente al patio de entrega, verificando su estado general en relacin con
el registrado a su ingreso. En caso de discrepancias, stas deben registrarlas en TripService y responsabilizarse con el cliente por medio de un seguro externo.
Cuando el cliente llega a retirar su vehculo, el supervisor le entrega el detalle de su orden de
trabajo con todas las tareas realizadas, materiales consumidos y repuestos utilizados. Con esto el cliente
cancela en caja y firma conforme la orden que el supervisor cierra en TripService.
Finalmente, el sistema TripService entrega un conjunto de indicadores que dan cuenta del rendimiento del servicio. La informacin destinada al jefe del taller y al gerente general del servicio autorizado es la siguiente:

Tiempos reales vs. estimados, con indicacin de los atrasos: Esta informacin es til para perfeccionar en el tiempo los estndares definidos para el sistema.

37

Costos reales vs. presupuestados, con indicacin de las desviaciones: Esta informacin tambin
sirve para mejorar los estndares.

El 20% de las tareas ms caras por unidad.

El 20% superior de los materiales ordenados por costo total consumido.

Costo promedio por orden de trabajo.

Lista de las discrepancias en los estados generales de ingreso y entrega de vehculos.

28) Problema del Sistema workflow Hi2Card para modelamiento en grupo:


1 Antecedentes
La empresa Jimnez & Jimnez se ha especializado en ventas al detalle de productos de bajo
costo tales como ropa, artculos de aseo y electrnicos menores. Esta empresa ha tenido un sostenido
crecimiento desde sus orgenes familiares. Por esta razn, ha decidido modernizar su imagen y estructura, pasando a denominarse Hi2Shop S.A. Dentro de su plan estratgico est el lanzamiento de una
nueva tarjeta de crdito (Hi2Card) para sus clientes y la creacin de la empresa Hi2Trans Ltda. para
administrar esta tarjeta.
Dentro de la empresa Jimnez & Jimnez el procesamiento de estos pagos era hecho en forma
manual, con algn apoyo de planillas electrnicas. Sin embargo, para la empresa Hi2Trans se requiere
desarrollar un sistema automatizado para este fin. La idea es concebirlo como un workflow, es decir,
definir un flujo de trabajo para procesar los documentos de pago, formularios, etc., asignando roles
especficos en los distintos procedimientos.
2 Sistema de Informacin a Ser Modelado
Al entrevistar a los empleados de Jimnez & Jimnez que van a trabajar en Hi2Trans, se obtuvo
la siguiente informacin para el sistema workflow Hi2Card.
La recepcionista recibe la correspondencia cada maana que un estafeta recoge en la casilla de
correos de la empresa o en el buzn de la tienda. La recepcionista abre y procesa el correo. Cada correspondencia puede contener informacin de distinto tipo (a veces incluye una carta adicional del
cliente):
1. Un cheque con Formulario de Pago.
2. Un cheque sin Formulario de Pago.
3. Un Formulario de Pago sin cheque.
4. Una carta del cliente.
La informacin contenida en el Formulario de Pago (formato tipo en anexo) es necesaria para
procesar el pago. La recepcionista llena la seccin PARA USO OFICIAL y enva el formulario y el
cheque a Departamento de Contabilidad. Las cartas son enviadas al Departamento de Servicio al Cliente (incluyendo los formularios sin cheque). Los cheques recibidos sin formulario son enviados al Departamento de Investigacin.

38

El empleado del Departamento de Investigacin recibe cheques de la recepcionista y comienza


revisando la informacin que el cliente ha provedo. Generalmente se tiene el nombre, la direccin, etc.
Si el nmero de cuenta del cliente es encontrado en las planillas de cuentas de clientes 13, el empleado
llena un Formulario de Pago en blanco para reemplazar al original no disponible y lo enva a Contabilidad. Si el nmero de cuenta no es hallado, se llena igualmente un Formulario de Pago con toda la informacin disponible y lo enva tambin a Contabilidad.
Al Departamento de Servicio al Cliente llegan las cartas. Todas estas cartas requieren de una
respuesta escrita. Las cartas se clasifican en 4 categoras:
1. Un error en el SALDO ACTUAL o en la DIRECCIN del cliente. Para esto el empleado de
Servicio a Cliente debe llenar el Formulario de Correccin de Saldo (formato en anexo) y enviarlo al Departamento de Correcciones.
2. Un reclamo sobre el servicio. El reclamo es investigado y se le enva una respuesta escrita al
cliente. Un informe de reclamos de clientes es elaborado mensualmente para el jefe del departamento.
3. Una solicitud de cesacin de pago de un cliente, indicando que el cliente no puede pagar debido
a algn problema. El empleado debe enviar al cliente en cuestin un Formulario de Solicitud de
Cesacin de Pago (en anexo).
4. Un Formulario de Solicitud de Cesacin de Pago se recibe (recepcin de caso 3) y se enva al
Departamento de Correcciones.
El jefe del Departamento de Servicio al Cliente recibe mensualmente un informe de reclamos de
clientes. Despus de analizar la informacin, el jefe elabora un informe resumido por tipo de reclamo
(por ejemplo, insatisfaccin con el servicio, problemas con la tarjeta de crdito o saldos actuales incorrectos) a la Gerencia General. Una encuesta trimestral de evaluacin del servicio es enviada a los
clientes. En el informe resumido se incluye informacin sobre la satisfaccin de los clientes de encuestas anteriores.
En el Departamento de Contabilidad, un contador recibe todos los cheques. Estos son registrados en la planilla de cuentas de clientes y se prepara un recibo de depsito para los cheques de cuentas
de clientes identificadas. Los cheques de cuentas de clientes desconocidas son depositados en una
cuenta de banco distinta denominada Pagos Sin Aplicacin. Los Formularios de Pagos son archivados
por nmero de cuenta. Diariamente se emite un informe de pagos por cliente (incluyendo los pagos sin
aplicacin) para el jefe del departamento.
En este departamento se reciben tambin, de tiempo en tiempo, los cheques devueltos del banco. Con ellos el contador llena un Formulario de Correccin de Saldo y lo enva al Departamento de
Correcciones, de tal manera de corregir el saldo actual del cliente. El contador enva tambin una carta
al cliente con respecto al cheque devuelto, requiriendo un nuevo cheque ms $10.000 de multa (que se
incluye como parte del saldo actual). Los cheques devueltos son archivados por nmero de cuenta y
nunca son redepositados.
Adems el contador entrega semanalmente a la jefatura, un informe de actualizacin con el saldo de cada cuenta de la planilla de cuentas de clientes que sufri alguna transaccin durante la semana.

13

Esta planilla tiene todos los datos de los clientes, los movimientos en sus cuentas y los saldos actualizados.

39

Finalmente, el Departamento de Correcciones recibe los Formularios de Correcciones de Deuda


y de Solicitud de Cesacin de Pago. Un empleado de este departamento realiza las correcciones correspondientes en la planilla de cuentas de clientes. Los formularios son entonces archivados por tipo y
nmero de cuenta. Se emiten adems informes diarios y mensuales de las correcciones realizadas para
el jefe de este departamento.

ANEXO
FORMULARIO DE PAGO
FECHA FACTURACIN:
/
/
PERIODO CUBIERTO:
CUENTA N:
NOMBRE:
DIRECCIN:
CIUDAD:
CAMBIO DE DIRECCIN: S / No
(A) PAGO ANTERIOR: $
(B) NUEVAS COMPRAS: $
(C) MONTO A PAGAR: $
SALDO ACTUAL (A) + (B) (C): $
PAGO MNIMO: $
PAGO ADEUDADO: $
PAGO REALIZADO EN EL PERIODO: $
PAGO INCLUIDO CON ESTE FORMULARIO: $
PARA USO OFICIAL
CDIGO OPERADOR:
FECHA RECEPCIN:
/
/
PAGO REALIZADO: $
CORRESPONDENCIA: S / No

AL

FORMULARIO DE CORRECCIN DE SALDO


FECHA:
/
/
CDIGO DE SERVICIO AL CLIENTE:
CUENTA N:
CAMBIO DE DIRECCIN: S / No
NOMBRE:
DIRECCIN:
CIUDAD:
(A) SALDO ACTUAL: $
(B) MONTO CORREGIDO: $
SALDO NUEVO (A) +/- (B): $
CDIGO AUTORIZACIN:
NMERO SUPERVISOR:
FIRMA SUPERVISOR:

FORMULARIO DE SOLICITUD DE CESACIN DE PAGO


FECHA:
/
/
CDIGO DE SERVICIO AL CLIENTE:
CUENTA N:
NOMBRE:
DIRECCIN:
CIUDAD:
CAUSAL DE CESACIN DE PAGO (MARQUE SLO UNA):
(1) __ FALLECIMIENTO (ADJUNTE CERTIFICADO DE DEFUNCIN) NO REQUIERE PAGO
(2) __ QUIEBRA (ADJUNTE DOCUMENTOS LEGALES) PLAZO DE 180 DAS
(3) __ REQUIERE REPROGRAMAR DEUDA PLAZO DE 60 O 90 DAS
PARA USO OFICIAL
CDIGO OPERADOR:
FECHA RECEPCIN:
/
/
CDIGO DE ACCIN: ( 1 / 2 / 3 )

40

29) Problema del Sistema Vitrineando.cl para modelamiento en grupo:


1 Antecedentes
La asimetra de la informacin entre oferentes y demandantes ha comenzado a disminuir desde
que se inici la comercializacin de productos y servicios por Internet. Cada vez que un consumidor
desea adquirir algn producto, puede obtener mucha informacin sobre el mismo gracias a la red. Esta
informacin puede ir desde especificaciones tcnicas del fabricante, hasta la opinin que tengan del
mismo otros consumidores que ya lo hayan experimentado.
Es en este contexto que un grupo de inversionistas nacionales han decidido ofrecer un servicio
por Internet denominado tentativamente Vitrineando.cl. La idea es que los consumidores (tanto personas como empresas) puedan acceder a informacin sobre la mayora de los productos comercializados
en Chile. Esta informacin puede ser tanto tcnica, como de opinin y principalmente, comparativa de
precios y de caractersticas. Formalmente, la misin propuesta para Vitrineando.cl, es la de ofrecer informacin til, actualizada y verdica para la toma de decisiones de consumo de las personas y empresas de Chile.
No est decidido an, segn el modelo del negocio, si el servicio se ofrecer mediante una suscripcin o en forma gratuita para los clientes, dependiendo del volumen de comisiones alcanzado con
los proveedores. Sin embargo, para el periodo de introduccin del servicio (de 6 meses a 1 ao), se
ofrecer gratuitamente a personas y empresas.
La operacin del sistema para sus usuarios ser completamente sobre Internet y se describe a
continuacin.
2 Sistema de Informacin a Ser Modelado
Los usuarios de Vitrineando.cl debern estar todos registrados para acceder a los servicios. Esto
es necesario para permitir hacer seguimiento a las compras que realicen. Los datos a registrar de cada
usuario son nombre, direccin, edad, sexo, correo electrnico, tramo de renta y preferencias sobre categoras de consumo (alimentacin, librera, automviles, etc.).
Los productos son desplegados en estas mismas categoras, pero tambin pueden ser buscados
por trminos especficos. Cada producto se describir con la mayor cantidad de datos tcnicos posibles,
provedos por los fabricantes o distribuidores y con una o ms fotos, si posible. Dentro de una categora, la descripcin ser estndar, por ejemplo, todas las cmaras digitales tendrn el mismo conjunto de
caractersticas. Tambin se mostrar informacin de opinin de otros consumidores, en la forma de una
evaluacin de la calidad del producto (un promedio entre 1 y 7) y de comentarios en general.
Al desplegar los productos de una misma categora (por ejemplo televisores), el usuario podr
indicar cules de ellos quiere comparar. El sistema entonces construir una tabla comparativa de caractersticas, colocando lado a lado los productos indicados, comparados por estas caractersticas.
En cualquier momento, el usuario podr agregar un producto a su carro de comparacin. Con
esto, el usuario podr pedir una comparacin de precios ofrecidos para los productos de su carro. Para
este efecto, el sistema se conectar directamente con los proveedores del producto 14, identificando to14

La comunicacin con los proveedores se har va Internet usando tecnologa XML.

41

dos los productos comparados y construir una tabla comparativa de precios, colocando lado a lado los
proveedores que ofrecen el producto, ordenndolos por precio de menor a mayor.
Los proveedores sern empresas de retail, distribuidores, representantes e importadoras en general, con los cuales Vitrineando.cl ya est negociando convenios que le permitirn acceder a sus bases
de datos para consultar precios. Ser indispensable que estos proveedores ofrezcan sus servicios por
medio de Internet 15. Adems, junto a cada proveedor se indicar la calificacin promedio obtenida por
la calidad de servicio ofrecido (tambin con nota de 1 a 7). Esta calificacin se obtendr a partir de la
evaluacin que cada consumidor har del proveedor, la cual podr ir acompaada de comentarios.
El usuario podr proveer el lugar a donde quiere le sea despachado el producto. Con esto, el
sistema considerar el costo del flete entre el proveedor y el usuario en cada producto. Esta informacin tambin la obtendr en lnea desde el proveedor. La tabla comparativa de precios se ordenar en
este caso por el precio final (= precio producto + flete). Si el usuario coloca ms de un producto en el
carro de comparacin, el sistema ofrecer adems una tabla conjunta de precios, para el mayor conjunto de productos que puedan comprarse de un nico proveedor, si esto es posible. Si existen varios
proveedores, entonces se mostrar slo el de menor precio total de los productos. Por ejemplo, si el
usuario indica que desea comprar una mquina de coser m, un telfono inalmbrico t y una caja de vinos c, el sistema le proporcionar inicialmente 3 tablas comparativas de precios, cada una con los proveedores para m, t y c. Asumiendo que existen 2 proveedores que ofrecen el producto m y t en conjunto, entonces el sistema calcular y ofrecer una tabla conjunta de precios con la menor suma de los precios de m y t de los proveedores encontrados.
A partir de cualquiera de las entradas de las tablas comparativa o conjunta de precios, el usuario
podr acceder, mediante un vnculo, al sitio de compras del proveedor, con el producto en cuestin ya
identificado; o a un formulario de pedido pre-llenado con el producto; o, en el caso ms simple, a un
mensaje estndar de correo electrnico con los datos del pedido para ser enviado al proveedor. Este
paso es particularmente importante, ya que por medio de las compras que recibirn los proveedores
desde el sitio de Vitrineando.cl, este ltimo percibir una comisin inicial del 2% del monto de la compra (esto depender de la negociacin con cada proveedor).
Finalmente, el sitio har un seguimiento y, en funcin de los plazos de despacho de las compras
del usuario, enviar mensajes de correo electrnico a los usuarios que accedieron a algn proveedor,
asumiendo que concretaron alguna compra a partir de Vitrineando.cl. En este mensaje se le pedir a los
usuarios para que accedan al sitio, y evalen con notas de 1 a 7, los productos adquiridos y al proveedor. Adems, podrn agregar los comentarios que estimen tiles a otros consumidores. Con esto se
piensa sentar las bases para una comunidad de consumidores que permitir la sustentabilidad de Vitrineando.cl.

30) Problema del Sistema Reunware para modelamiento en grupo:


1 Antecedentes
Desde siempre las personas se han reunido para emprender actividades. Los propsitos comunes
para los miembros de un grupo de personas, permiten aunar esfuerzos y coordinar tareas. Esta necesi15

En realidad, en algunos casos se aceptarn pedidos por correo electrnico, pero lo ideal es que tengan un sitio desde el
cual se pueda comprar.

42

dad de reunirse est presente en muchos mbitos: clubes sociales, organizaciones deportivas, grupos de
afinidad o grupos de estudio, pero es an ms crtica en el mundo de los negocios, donde las reuniones
de trabajo toman gran parte del tiempo laboral de los miembros involucrados. Es sabido lo difcil que
puede ser organizar una reunin en que todos o al menos la mayora de los participantes pueda asistir.
Reconociendo esta realidad, la empresa I3R 16 Ltda. ha decidido disear el sistema Reunware,
que espera sea til para apoyar la gestin de reuniones o compromisos en general. La idea es ofrecerlo
como un servicio externalizado que puede operarse en los servidores de I3R. Las empresas podrn contratar este servicio sobre la base de una suscripcin anual, pero se ofrece un periodo de prueba de hasta
3 meses para que sus empleados concierten libremente compromisos. La idea es que despus de usarlo,
ya no puedan vivir sin l.
La operacin del sistema para sus usuarios ser completamente sobre Internet y se describe a
continuacin.
2 Sistema de Informacin a Ser Modelado
Una vez que una empresa ha contratado el servicio, se crea una base de datos disponible para
ella y el acceso a una cuenta de administrador, a partir de la cual se podrn crear grupos de trabajo,
registrar personas, definir periodos de asignacin (generalmente 30 15 minutos), fijar el lmite de
reserva de tiempo para compromisos (normalmente 10 20%), etc.
Inicialmente se registran todas las personas que usarn el servicio, asignndoles un nombre de
usuario y una contrasea. Cada persona debe llenar sus datos personales, como direccin, telfono,
correo electrnico, foto, etc. El administrador crea entonces grupos de trabajo que corresponden a conjuntos de personas y/u otros grupos de trabajo. Los grupos deben tener al menos 2 personas como para
poder concertar compromisos. Las personas obviamente pueden pertenecen a varios grupos de trabajo.
Cada persona debe llenar su agenda personal, de acuerdo a los compromisos estndares del cargo que desempea, como por ejemplo atencin a clientes, capacitaciones, reuniones de evaluacin,
visitas a terreno, etc. Esto configura una matriz semanal con los periodos de asignacin y los das hbiles. Cada entrada de la agenda personal puede ser fija (tiene un compromiso inamovible), flexible (tiene un compromiso cambiable) o puede estar disponible. Las personas tienen derecho a definir, hasta el
lmite de reserva de tiempo, compromisos reservados. La tabla 1 muestra un ejemplo especfico de una
agenda personal. Esta agenda personal es pblica, en la forma mostrada, para todos los miembros de
los grupos a los cuales pertenezca esta persona.
Cualquier persona de un grupo puede solicitar al sistema Reunware un nuevo compromiso o la
modificacin de uno ya programado. En el caso de un nuevo compromiso, el solicitante debe indicar el
nombre del mismo, si es puntual o peridico, la ventana de programacin (desde y hasta cundo se
puede programar) y cul es su duracin. Reunware busca las fechas y horas posibles para todos los
miembros del grupo, entregando una lista ordenada con las opciones posibles. El solicitante debe entonces indicar la opcin elegida, junto con el objetivo del compromiso y calidad de fija o flexible, con
lo que Reunware lo incluir en las agendas de todos los miembros del grupo y les enviar un mensaje
de correo electrnico de aviso. El solicitante tambin puede indicar cunto tiempo antes se le debe enviar un 2 correo electrnico recordatorio (por ejemplo, el da hbil antes o en la maana para un com16

Ingenieros Industriales e Informticos Reunidos

43

promiso en la tarde). El solicitante puede incluso colocar documentos, archivos, vnculos, etc. asociados al compromiso, de tal manera que las personas involucradas puedan accederlos desde su agenda
personal.
Tabla 1 Ejemplo de una semana tpica de una agenda personal.
Noviembre
2005

Lunes 21

Martes 22

Mircoles 23

Jueves 24

Viernes 25

08:30 ~

[F] Reunin Comit


Ventas 1/3

09:00 ~

[F] Reunin Comit


Ventas 2/3

[F] Reunin proyecto


ABC 1/5

09:30 ~

[F] Reunin Comit


Ventas 3/3

[F] Reunin proyecto


ABC 2/5

[F] {reservado} 7/8

[F] Reunin proyecto


ABC 3/5

[F] {reservado} 8/8

[X] Reunin comit fin de


ao 1/1

10:00 ~
10:30 ~

[F] Visita proveedor


Internet 1/2

11:00 ~

[F] Visita proveedor


Internet 2/2

...

...

[X] Entrevista estudiantes en prctica 1/2

[F] {reservado} 5/8

[X] Entrevista estudiantes en prctica 2/2

[F] {reservado} 6/8

[F] Reunin proyecto


ABC 4/5
[F] Reunin Gerente
RRHH 1/1

...

[F] Reunin proyecto


ABC 5/5

...

...

16:30 ~

[F] Revisin informe


Gerencia 1/2

[F] {reservado} 1/8

[F] {reservado} 3/8

17:00 ~

[F] Revisin informe


Gerencia 2/2

[F] {reservado} 2/8

[F] {reservado} 4/8

...

[X] Convivencia Seccin


Ventas 1/1

Notacin: F = Fija, X = fleXible

Si se trata de modificar un compromiso, el solicitante puede cambiar cualquiera de sus propiedades (nombre, periodicidad, grupo, ventana, duracin, etc.) y someterlo a Reunware, que lo trata como
un nuevo compromiso, asumiendo la inexistencia del compromiso original. Una vez confirmado el
cambio, Reunware elimina el compromiso original 17 e ingresa el compromiso modificado, informando
del cambio a todos los involucrados.
Dada las restricciones del nmero de participantes, la duracin del compromiso y la ventana de
programacin, no es posible asegurar que existan opciones que usen slo entradas disponibles de las
agendas personales de todos los miembros del grupo. Por esta razn, Reunware siempre debe ofrecer
alternativas, en las cuales una o ms personas del grupo tienen compromisos flexibles o simplemente
no pueden participar por tener compromisos fijos. Estas alternativas son mostradas al solicitante individualizando a las personas afectadas.
Si el solicitante opta por una de estas alternativas, Reunware informa a las personas cuando no
puedan asistir o deban cambiar algn compromiso flexible para poder asistir. Es de responsabilidad de
cada persona la modificacin de los compromisos flexibles de su agenda.

17

Esto se aplica tambin cuando slo se desea eliminar un compromiso.

44

El solicitante puede indicar tambin que algunas personas, para un compromiso dado, son del
tipo NPF (No Puede Faltar). Estas personas deben cambiar compromisos flexibles anteriores cuando
entren en conflicto. En aquellas situaciones en que sea imposible programar un compromiso con estas
personas, el sistema les avisa que tienen un compromiso pendiente, debiendo resolverlo directamente
con el solicitante o modificando su agenda personal. Por otra parte, el solicitante siempre puede cambiar a las personas NPF, destrabando compromisos en esta situacin.
Otro aspecto interesante de Reunware, es la concepcin de la importancia de programar compromisos con antelacin. En trminos simples: mientras ms temprano, mejor. Esto se percibe, por
ejemplo, en que las opciones para un compromiso se ordenan priorizando la programacin ms temprana posible. Tambin se priorizan, para las personas no consideradas NPF, los compromisos programados con anterioridad por sobre los nuevos.
A medida que la base de datos de la empresa se va completando con personas, grupos y compromisos, es posible que el administrador acceda a algunas estadsticas sobre ellos. Se estima que esta
funcionalidad es slo un punto de partida y necesariamente se ir extendiendo a medida que las empresas lo soliciten 18. En un principio, es posible conocer para un periodo solicitado:
Personas ordenadas por el nmero de compromisos
Compromisos ordenados por duracin
Grupos ordenados por nmero y duracin de compromisos
Carga de compromisos por persona y grupo

31) Problema del Sistema SABUS para modelamiento en grupo:


1 Antecedentes
Dentro de los planes de modernizacin del transporte pblico en Chile, se ha considerado la
descentralizacin de los terminales de buses, de manera de evitar fuertes inversiones en gran infraestructura, a favor de terminales locales de menores dimensiones.
Un terminal de buses consiste en un conjunto de andenes donde los buses se detienen para tomar y/o dejar pasajeros. Los buses realizan rutas circulares que empiezan y terminan en un andn. A
cada ruta se le denomina una lnea. En un terminal con asignacin esttica de andenes, cada andn tiene
un nmero de lneas asignadas, de tal manera que un bus de la lnea siempre termina en el mismo
andn. Como los buses estn en servicio la mayor parte del tiempo, existe un claro desperdicio de espacio en los andenes vacos. Para ahorrar espacio en reas con mayor densidad poblacional, se han concebido los terminales compactos dinmicos de buses (TCDB).
Un TCDB consiste en pocos andenes a los cuales se le asignan buses en funcin de la necesidad. La asignacin es hecha cuando el bus se acerca al terminal, de tal forma de optimizar el uso de los
andenes. Al sistema responsable de realizar esta asignacin se le denomina SABUS (Sistema de Asignacin de BUSes).

18

De hecho, se ofrece la posibilidad de que las empresas soliciten a lo ms 2 nuevos tipos de informacin por ao de contrato, sujetos a factibilidad tcnica. Estos tipos de informacin se reservan para la empresa solicitan, hasta hacerlos disponibles
para todos los clientes en la siguiente versin de Reunware (a cada 12 18 meses aproximadamente).

45

2 Sistema de Informacin a Ser Modelado


Un TCDB consiste en un conjunto de andenes, sensores y pantallas de informacin. SABUS
tiene acceso a sensores en las carreteras de aproximacin al terminal, con el fin de determinar cuando
un bus est llegando. Tambin existen sensores en las entradas y salidas de terminal que comunican
cuando los buses entran o dejan el terminal, y sensores en los andenes que indican cuando un bus est
detenido en ellos. Un andn se reserva para los buses que, por alguna razn, no pudieron detenerse en
su andn asignado. A este andn se le denomina andn de trnsito. Cada bus tiene una pantalla que
despliega los mensajes enviados al conductor. A esta pantalla se le denomina pantalla de instrucciones
del conductor. El sistema SABUS tiene una comunicacin inalmbrica 19 con estas pantallas. El terminal propiamente tal tiene tambin varias pantallas de informacin para pasajeros, donde se les informa
sobre las asignaciones de andenes de los buses.
Las rutas seguidas por los buses estn divididas en lneas. Cada lnea tiene exactamente una ruta
a seguir, que se inicia y termina en el terminal de buses. Cuando un bus hace un viaje, debe seguir la
ruta de una lnea. Cada da, uno o ms buses pueden hacer varios viajes de una lnea. Para cada lnea
existe un andn preferido, que se reserva para dicha lnea durante periodos de tiempo especficos del
da. SABUS debiera asignar a un bus entrante en el andn preferido de su lnea, tantas veces como sea
posible. Para esto se tiene acceso al paquete de programacin lineal CPlex, que calcula las asignaciones
ptimas. Cuando un bus ingresa al terminal, SABUS debe instruir al conductor respecto del andn
asignado al viaje y tambin debe informar a los pasajeros que estn en el terminal.
Cuando el bus est en viaje, se tiene un estimado de hora de regreso. Si est retrasado, SABUS
debe anunciarlo a los pasajeros del terminal. Cuando el bus est cerca del terminal, debe anunciarlo
tambin a los pasajeros, as como debe instruir al conductor del andn asignado dinmicamente. Si al
ingresar el bus al terminal, el andn asignado se encuentra ocupado por cualquier razn, el bus debe
esperar en el andn de trnsito hasta que se libere el andn asignado. Slo en este momento pueden
bajar los pasajeros del bus.
Finalmente, para el jefe de operaciones del terminal, SABUS debe valorizar algunos indicadores
que den cuenta del desempeo del TCDB, todos de acuerdo a algn periodo indicado por el jefe:
Tasa de buses entrantes y salientes.
Promedio de atraso de los buses.
Tasa promedio de uso del andn de trnsito.

32) Problema del Sistema CompartAuto Local para modelamiento en grupo:


1 Antecedentes
Es sabido que la alta congestin en las grandes ciudades contribuye a la contaminacin y reduce
la calidad de vida de sus ciudadanos en general. En muchos pases, entre ellos Chile, se est tratando de
cumplir con las obligaciones, producto de los acuerdos internacionales de reduccin en la emisin de
carbono a la atmsfera, para evitar el calentamiento global. Como una respuesta a esta situacin, la
empresa CompartAuto Internacional promueve el transporte compartido.

19

Con un alcance hasta 200 m aproximadamente.

46

En muchas reas, el transporte pblico ha disminuido al mismo tiempo que el nmero de vehculos particulares ha aumentado, y no existe una infraestructura de transporte pblico para hacer frente
a la demanda de personas que pudieran dejar de usar sus autos para ir y volver del trabajo o estudio.
Los modelos de autos compartidos ofrecen una solucin de corto plazo para reducir el trfico, sin necesidad de inversiones inmediatas en infraestructura.
CompartAuto Internacional busca que las personas compartan transporte, proveyendo el servicio a potenciales compartidores de auto que vivan y trabajen cerca unos de los otros. Es comn que
personas que trabajan juntas comparten informalmente transporte, pero es ms difcil que personas que
trabajan o estudian cerca una de la otra, encuentren a alguien que comparta transporte. No es raro que
en algunas grandes empresas o universidades, existan personas que trabajen o estudien en el mismo
lugar sin siquiera conocerse.
CompartAuto Internacional opera como una organizacin sin fines de lucro. Dependiendo del
pas, CompartAuto ofrece sus servicios al gobierno local y a grandes organizaciones que pueden tener
obligaciones legales para reducir el trfico en algunos pases o estados. Adems debe realizar publicidad de sus servicios al pblico en general. Las personas que se afilien deben pagar una cuota mensual
de membresa, que es reembolsada si CompartAuto no logra encontrar quien pueda requerir u ofrecer el
transporte. CompartAuto debe establecer contratos entre los participantes, para asegurar que el dinero
que cambia de manos pueda cubrir, al menos, los gastos de combustible y preocuparse adems de las
implicaciones para asegurar los autos compartidos. Acta como un corredor de compaas de seguro 20
para cubrir los autos compartidos.
El equipo que trabaja en CompartAuto local requiere un extenso entrenamiento, que incluye la
consultora que puedan ofrecer a organizaciones como al gobierno local, la legislacin de su propio
pas o estado, los requerimientos de seguros, consideraciones de seguridad y la operacin de los sistemas de CompartAuto. En algunos pases, las regulaciones de la industria de seguros exigen adems que
el personal de CompartAuto deba cumplir ciertos requisitos.
El modelo de negocio de CompartAuto define que los retornos de su actividad provienen de una
combinacin de las cuotas de membresa, los ingresos por consultoras y las comisiones sobre la venta
de seguros. Un porcentaje de todos los ingresos es entregado a la operacin central de CompartAuto
Internacional y el resto es mantenido por CompartAuto local.
A medida que el nmero de autopistas concesionadas aumenta, CompartAuto local vender e
instalar el equipamiento 21 necesario para los miembros, as como trabajar con las autoridades y empresas concesionarias correspondientes, para negociar descuentos a sus miembros sobre la base de la
reduccin en la demanda de trfico.
2 Sistema de Informacin a Ser Modelado
CompartAuto Internacional requiere un sistema computacional para ser utilizado por
CompartAuto local. La idea es ofrecer el servicio en cada pas con un sistema computacional de apoyo
desde el inicio de sus operaciones. En cada pas deber haber al menos un servidor web que proveer
informacin actualizada sobre los servicios y el corretaje de seguros para CompartAuto local, as como

20
21

Existen estudios que han demostrado que los dueos de autos compartidos tienen un bajo nivel de riesgo.
Los tags.

47

permitir el registro en lnea de miembros de CompartAuto. La informacin sobre los miembros podr
ser descargada a los sistemas correspondientes de CompartAuto local.
Los requerimientos del sistema de CompartAuto local se indican a continuacin.
El sistema debe mantener informacin sobre los miembros, permitiendo registrar los detalles de
potenciales compartidores de autos, ya sea ofreciendo transporte, buscando transporte o ambos, as como la ubicacin geogrfica de su hogar y lugar de trabajo/estudio. Debe ser posible descargar estos
detalles desde el servidor web.
Para identificar miembros que puedan compartir transporte, el sistema debe verificar las ubicaciones geogrficas 22 y los tiempos de viaje correspondientes y registrar los detalles de arreglos de autos
compartidos que resulten. Aquellos miembros que no logren compartir transporte deben estar siempre
en una lista de correos electrnicos descargable
Tambin se debe registrar toda la informacin de los contactos y visitas del equipo de
CompartAuto local a los clientes de consultora (empresas, universidades, etc.).
Respecto a los pagos, el sistema debe proveer una interfaz para el sistema transaccional de tarjetas de crdito y el sistema de transferencia electrnica de fondos 23, para procesar los pagos de cuotas de
membresa y los reembolsos.
Las ventas de seguros tambin deben registrarse, con los detalles de las plizas vendidas a los
miembros, las compaas de seguro involucradas y las renovaciones peridicas. Los ingresos provenientes de las plizas tambin deben quedar registrados.
Finalmente, el sistema debe permitir una expansin futura para incorporar informacin sobre los
concesionarios y esquemas de pago en las autopistas concesionadas y sobre el equipamiento vendido e
instalado por los miembros. Esto se sugiere incluirlo ahora en el diseo del sistema, para ser posteriormente desarrollado.

33) Problema del Sistema Sitio Total Remote para modelamiento en grupo:
1 Antecedentes
Con el crecimiento explosivo de los dispositivos electrnicos con control remoto (TV LCD,
DVD player, sistemas home theater, aire acondicionado, etc.), se ha transformado en un problema para
los hogares el lidiar con varios controles remotos. No es extrao que un usuario tenga que decidir entre
4 5 controles, cul va a usar y para qu dispositivo. Para hacer frente a este problema en el mercado
se han propuesto 3 soluciones con diferentes niveles de sofisticacin.
Una primera solucin barata y simple es un control remoto universal que tiene los principales
comandos de varios dispositivos de las principales marcas, pero esto no siempre sirve a las necesidades
de todas las personas, ya que pueden requerir comandos no incluidos o simplemente no contar con los
cdigos de algn dispositivo en particular.
22
23

Las direcciones son asignadas ubicaciones geogrficas de 60.000 m2 (aproximadamente 4 manzanas).


Cargo en cuenta corriente o pago en lnea.

48

Una segunda solucin es la de un control remoto universal con capacidad de aprendizaje de


cdigos. La idea es que si se cuenta con el control remoto original, se puede emitir la seal y grabarla
en el control remoto universal, para agregarla a los cdigos estndares. Esto permite incluir cualquier
dispositivo, pero exige tener funcionando el control remoto original.
La tercera solucin es proveer un conjunto centralizado de
cdigos de dispositivos, disponible para los usuarios que pueden ser
utilizados en un control remoto configurable. Esta solucin es la ms
elaborada, porque exige que los usuarios puedan conectarse remotamente a una base de datos. Para esto, la empresa Total Remote ha diseado la lnea Navitus de controles remotos (ver figura al lado) con
pantalla LCD sensible al tacto (touchscreen), totalmente configurable
y con conexin USB para el PC. Los diferentes modelos de la lnea
difieren esencialmente en la memoria disponible, el tamao de la pantalla LCD y si sta es color o blanco/negro.
Para el lanzamiento de esta lnea de controles remotos, Total
Remote deber disear el sitio web que ofrece el acceso a la base de
datos de cdigos, como un sistema que es crtico para la generacin de
valor de los productos ofrecidos.
2 Sistema de Informacin a Ser Modelado
Una vez los usuarios han adquirido un control remoto, se les proveer un CD que los conecta al
sitio de registro de clientes de Total Remote para crearles cuentas con nombre de cliente y contrasea
personal de acceso. Seguidamente al procedimiento de registro, el cliente deber conectar su control
remoto va USB, para registrar el modelo del mismo y su versin de firmware.
Es posible que un cliente tenga varios controles remotos del mismo modelo o de otro. En este
caso, se le permitir que agregue cuntos controles quiera con el procedimiento de identificacin del
control remoto. Tambin podr eliminar cualquiera de sus controles. Si quiere, podr clonar un control
remoto que ya tenga registrado para hacerle modificaciones despus. En el caso de que el cliente tenga
ms de un control remoto, deber nominarlos distintamente y se le pedir siempre que seleccione sobre
cul control trabajar en cada sesin de conexin al sitio de Total Remote.
Una vez registrados el cliente y su(s) control(es) remoto(s), podr conectarse las veces que quiera para identificar los dispositivos que desee controlar con un control remoto especfico. El sitio le
ofrecer seleccionar el tipo de dispositivo, la marca y el modelo. Una vez seleccionado se incorporar
como parte del equipamiento del cliente asociado al control remoto. Si el dispositivo no existe, el sistema le entregar el modelo inmediatamente superior y/o inferior que probablemente satisfaga en buena
parte los cdigos del faltante 24. El cliente tambin podr decidir por hacer aprender a su control remoto.
En este caso deber contar con el control original, el sistema le solicitar que los coloque en posicin
(emisor y receptor de infrarrojo) y luego le pedir que presione cada comando, de acuerdo a un layout
estndar del tipo de dispositivo que controla. Una vez concluido, el sistema registrar para el cliente
24

Por ejemplo si solicit el DVD player Panasonic DH-55S y ste no est disponible, el sistema le ofrecer los modelos
DH-50S y DH-60B como alternativos.

49

estos cdigos y avisar por correo electrnico al Laboratorio Tcnico de Total Remote, para que evale
la incorporacin futura de los mismos a la base de datos.
Es importante destacar que cada vez que el cliente se conecta, el sistema deber verificar si
existe alguna versin actualizada de firmware para el control remoto liberada por el Laboratorio Tcnico, y si es as, deber recomendar su descarga para la actualizacin.
Cuando el cliente indique haber terminado la actualizacin de su control remoto, descargar la
actualizacin de firmware (si es el caso), los cdigos de cada dispositivo de su equipamiento, en conjunto con los layout estndares para cada uno de ellos 25. Esta descarga se instalar en su control remoto, comandado por el firmware original o el recin actualizado. Con esto, el cliente podr operar su
control remoto seleccionando el dispositivo y visualizando en la pantalla el layout estndar correspondiente.
Adems el cliente podr definir macros como secuencias de comandos de uno o ms de los dispositivos de su equipamiento, que le permitirn controlarlos en conjunto. Por ejemplo, el cliente podr
definir una macro para encender el TV, el DVD player y el sistema home theater y dejar el layout del
DVD player por omisin. Las macros quedarn almacenadas slo en su control remoto y estarn limitadas nicamente por su memoria disponible 26.
El cliente tambin podr conectarse para personalizar su control remoto. Mediante esta funcionalidad podr alterar los comandos de cualquier dispositivo, ya sea asignndole otros cdigos aprendidos, eliminando algn comando o incluso agregando nuevos. Adems podr personalizar el layout
estndar de modo que muestre los comandos que l quiera. Incluso podr crear nuevos dispositivos,
dentro de los tipos disponibles, con los layout y cdigos que desee.
El Laboratorio Tcnico estar permanentemente agregando o actualizando cdigos y firmware,
para que los clientes puedan descargarlos. Para esto, el sistema deber verificar las versiones de cdigos de cada dispositivo del equipamiento de los clientes para recomendar su actualizacin.

34) Problema del Sistema EFT para modelamiento en grupo:


1 Antecedentes
Un sistema de transferencia electrnica de fondos o EFT (Electronic Funds Transfer) consiste
bsicamente en un conjunto de procedimientos, tecnologas y plataformas que permite que los clientes
con cuentas en alguna institucin bancaria, puedan transferir montos de dinero a otra cuenta, sin la utilizacin de documentos en papel o moneda. La masividad que hoy tienen los sistemas de banca
electrnica, permite que se puedan realizar fcilmente estas transferencias en 24 horas.
Para que un sistema de estas caractersticas pueda operar, se requiere de una organizacin centralizada (Centro de EFT o CEFT) que coordine las transferencias entre las distintas entidades bancarias asociadas. Cada entidad debe comunicar diariamente las transferencias realizadas a todas las otras
25

Los layouts dependen del modelo del control remoto del cliente, ya que pueden desplegar distinta cantidad de comandos y
con opcin en colores (ver figura).
26
Esto depender de cuntos dispositivos tenga en su equipamiento, cuntos cdigos maneja cada dispositivo, como as
tambin de cuntas macros grabe y cuntos comandos componen cada macro.

50

entidades, y las entidades receptoras recibir y verificar estas transferencias. Con esto se construye una
denominada matriz EFT que indica las transferencias aceptadas y rechazadas por cada par de entidades
involucradas y permite obtener los montos netos entre las mismas.
2 Sistema de Informacin a Ser Modelado
Al cierre de un da hbil cualquiera (24:00), los clientes que poseen cuentas pueden haber solicitado transferencias de montos a cuentas de otras entidades 27. Cada entidad construye una lista de emisor EFT 28 donde se indican los datos de la cuenta emisora de la transferencia (banco, nmero, tipo,
RUT titular, nombre titular), de la transferencia (monto, asunto, fecha, hora) y de la cuenta receptora de
la transferencia (banco, nmero, tipo, RUT titular, nombre titular). Esta lista se recibe hasta las 3:00 del
da siguiente en el CEFT. Apenas se recibe la lista, sta es validada para ver si tiene algn error. Si es
as, es devuelta inmediatamente para que pueda ser reenviada dentro del horario. Cada lista de emisor
EFT recibida y verificada es dividida en sublistas por entidad receptora, con lo que se obtiene un conjunto de listas de receptor EFT, que son enviadas a las respectivas entidades. Se incluye, para cada
transferencia y en todas las listas de receptor, un EFTid (identificador de la transferencia) nico para
todo el sistema, que asegura su identificacin por al menos 6 aos.
Cada entidad que recibe una lista de receptor EFT tiene hasta las 6:00 para verificar si la cuenta
receptora es vlida o no y aceptar o rechazar la transferencia. Con esto construye una lista de resultados
del receptor EFT que es enviada al CEFT. Esta lista consigna, adems de los datos recibidos en la lista
de receptor, un resultado de la transferencia que puede ser aceptada o rechazada, y en este ltimo caso
se agrega la causa. El CEFT contrasta la lista de resultados del receptor EFT con la lista de receptor
EFT. Si son consistentes, registra los resultados en la matriz EFT y enva dicha lista de vuelta al emisor
correspondiente. Si hay inconsistencias, la lista de resultados es devuelta al receptor para su posterior
reenvo dentro del horario. Con las listas de resultados de los receptores EFT, cada emisor puede informar a sus clientes el estado final de las transferencias solicitadas.
Cuando se tiene la matriz EFT completa o a las 6:30 29 (lo que ocurra primero), se netea la
matriz EFT, para determinar cunto es el monto total que debe transferirse entre cada par de entidades
bancarias involucradas en las transferencias. La matriz tiene la estructura de la tabla 1, donde las filas
representan las entidades emisoras (Ei), las columnas las entidades receptoras (Ej) y cada entrada (salvo
la diagonal) contiene el monto total de transferencias emitidas por Ei a Ej (eij) y el monto total de transferencias rechazadas (rij) de Ei a Ej.
Por filas, el neto que el emisor Ei debe transferir a Ej se calcula como nij = eij rij (eji rji), con
i j. Si nij < 0, entonces Ej debe transferir el monto -nij a Ei. El resultado de cada neto entre emisor y
receptor es informado a las entidades, las cuales deben gestionar la transferencia entre ellas, antes de
las 9:00.
Desde el punto de vista del cliente de una entidad bancaria, todo este proceso es transparente. l
define un EFT indicando el monto a transferir y el banco del receptor, su nmero de cuenta, el RUT,
27

Se asume que las transferencias entre cuentas de un mismo banco son resueltas sin acceder a este sistema.
Esta lista era texto simple en versiones anteriores, pero ahora se ha optado a tecnologa XML para facilitar la migracin a un futuro sistema descentralizado en lnea.
29
Estos horarios deben respetarse rigurosamente cuando el da siguiente tambin es hbil. Si no lo es, los horarios
lmites cambian de 3:00 a 10:00, de 6:00 a 14:00 y de 6:30 a 15:00.
28

51

correo electrnico (opcional) y nombre del titular de la cuenta y el asunto de la transferencia (tambin
opcional). La entidad comunica al emisor y receptor (si es posible) la transferencia solicitada, carga el
monto a la cuenta de su cliente y define la transferencia como pendiente. Al otro da, el cliente recibe el
resultado de aceptada o rechazada. En este ltimo caso, recibe la causa del rechazo y el abono por el
monto que se intent transferir.
Tabla 1 Ejemplo genrico de una matriz EFT.
Receptor
Emisor

E1
Ei

E1

E2

Ej

En

(e12, r12)

(ei1, ri1)

(e1j, r1j)
(eij, rij)

(e1n, r1n)
(ein, rin)

...

En

(en1, rn1)

(en2, rn2)

(enj, rnj)

Finalmente, el CEFT genera informes pblicos mensuales y un acumulado de los ltimos 12


meses, resumiendo las transferencias que se han concretado entre todas las entidades bancarias del sistema. Se indican los montos aceptados, rechazados y los netos, con los respectivos totales.

35) Problema del Sistema Revista Industria para modelamiento en grupo:


Una pequea publicacin sobre temas de Ingeniera Industrial denominada Revista Industria ha
crecido sostenidamente en los 8 aos desde su fundacin, pero sus sistemas no se han modernizado
acorde con este crecimiento. Actualmente funciona usando planillas electrnicas, procesadores de texto
y bases de datos simples en distintos computadores en red.
Industria se publica 11 veces al ao (no se publica en el mes de Febrero), y cada edicin consiste entre 5 y 10 artculos escritos por uno o ms autores del rea de Ingeniera Industrial. Aunque los
autores no reciben ningn pago por sus artculos, se les entrega una suscripcin anual gratuita como
atencin por su esfuerzo. Si ya cuentan con una suscripcin, la fecha de expiracin se extiende por un
ao. La mayora de los autores ha escrito un nico artculo durante estos aos, pero unos pocos han
escrito varios. A la direccin de la revista le preocupa saber de esta frecuencia de publicacin de los
autores, ya que quiere evitar tener ms de dos artculos de un mismo autor dentro de un ao calendario.
Industria tiene un comit editorial, cuyos miembros pueden ser autores de vez en cuando. Este
comit editorial se renueva a cada 2 aos y sus miembros reciben suscripciones por el tiempo en que
pertenecen al mismo. Este comit tiene como propsito revisar los artculos sometidos a publicacin,
proponer al editor y al director de la revista tpicos relevantes para futuras ediciones, y sugerir autores
que podran contactarse para escribir artculos sobre estos tpicos. Como cualquier publicacin seria,
las ediciones se planifican con meses de adelanto, por lo que el editor debe gestionar varias ediciones
simultneamente, recibiendo numerosos artculos de una variedad de autores.
Industria slo se vende en modalidad de suscripcin anual, pero tambin se han aceptado suscripciones por periodos mayores o menores a un ao, calculando proporcionalmente respecto del precio
anual. Actualmente se cuenta con casi 4.000 suscriptores, la mayora de ellos corresponde a empresas y
el resto a personas naturales que piden se les enve a direcciones comerciales o residenciales su copia

52

mensual. Algunas grandes empresas piden mltiples copias que se envan a una misma persona 30. Se
hace un descuento de 10% por cada copia adicional a la de una suscripcin. De vez en cuando se hacen
ofertas de descuento en las suscripciones, especialmente para alumnos de ltimo ao de universidades
y profesionales recin egresados. Sin embargo la mayora de las suscripciones tienen el precio estndar 31.
Hay algunas suscripciones de mltiples copias en que las empresas solicitan los envos separadamente. En estos casos es importante tener claro el suscriptor principal del cual se recibe el pago y a
quien hay que dirigir cualquier correspondencia. Generalmente las ediciones son enviadas a mltiples
personas en una localizacin (por ejemplo, una divisin o departamento en una direccin). Sin embargo, en algunos pocos casos, las mltiples copias son enviadas a personas en diferentes localizaciones de
una empresa. En cualquier caso, se considera conveniente identificar los suscriptores dentro de una
localizacin y las distintas localizaciones asociadas a una empresa.
Adems de las suscripciones gratuitas para los autores y miembros del comit editorial, el director enva suscripciones como obsequios a gurus respetados del rea, como tambin a autoridades,
acadmicos y algunos amigos de la revista. Esta lista obseq 32 se revisa de vez en cuando para ver si hay
alguien que eliminar. Peridicamente se consulta a los miembros de la lista obseq para confirmar si les
interesa seguir recibiendo las ediciones de Industria.
Un gran porcentaje de los suscriptores existentes renuevan sus suscripciones de un ao para el
otro. Tpicamente, se enva avisos mensuales 3 meses antes de la expiracin de la suscripcin. En el
mes final de la suscripcin, se incluye con la revista una nota con letras grandes que dice ESTA ES
SU LTIMA COPIA DE INDUSTRIA. Por 3 meses despus que ha expirado una suscripcin no renovada, se enva mensualmente avisos de recordatorio. Las renovaciones pueden seguir ocurriendo
varios meses despus que ha expirado una suscripcin, por lo que no se eliminan los registros que se
tengan de ellas.
Las nuevas suscripciones y renovaciones se reciben en un formulario debidamente llenado, con
pagos en cheques, depsitos electrnicos o con tarjetas de crdito. En algunos casos los suscriptores
solicitan la emisin de una factura con el nmero de la orden de compra que acompaa al formulario,
para poder procesarlo contablemente en su empresa.
Tambin es posible vender algunas ediciones anteriores de Industria 33, las cuales pueden solicitarse por medio del mismo formulario de suscripcin. En raras ocasiones, un cliente puede pedir mltiples copias de una edicin anterior, en cuyo caso se ofrece un descuento de 10% a partir de la 2 copia.
Aprovechando la posibilidad de contar con un sistema de informacin integrado de apoyo a la
publicacin de Industria se deseara contar inicialmente con lo siguiente:
Distribucin de las suscripciones en el tiempo (base mensual), proyectando la duracin a futuro
de las mismas.
30

En este caso, se debe definir un representante de la empresa para efectos de la suscripcin. Otras empresas prefieren definir un cargo a quien dirigir las copias, como por ejemplo bibliotecario.
31
El precio estndar es dentro del pas. Las suscripciones internacionales tienen un costo adicional debido al flete y
se calcula especficamente para cada pas.
32
Se le denomina as por el nombre de la planilla que los contiene: obseq.ods
33
Esto siempre sujeto a la disponibilidad del momento, la cual generalmente se consulta y/o confirma en forma telefnica con el encargado de suscripciones.

53

Proporcin de suscripciones de empresas/personas naturales, mltiples/nica copia, nacionales/internacionales, vigentes/expiradas, normales/obsequios


Otra propuesta de informacin til para la revista, a juicio de los modeladores.

36) Problema del Sistema Herramienta SimPetri para modelamiento en grupo:


1 Antecedentes
Las redes de Petri fueron propuestas en 1962, en la tesis doctoral denominada Kommunikation
mit Automaten (Comunicacin con autmatas) de Carl Adam Petri, donde el autor formul las bases
para una teora de comunicacin entre componentes asincrnicos de un sistema computacional. El
nfasis de la propuesta original estaba en las relaciones causales entre los eventos y particularmente en
la concurrencia de los sistemas.
Con ms de 45 aos de investigacin, las redes de Petri se han enriquecido con interesantes extensiones, entre las cuales se pueden mencionar, el desarrollo de distintas clases (condicin/evento,
lugar/transicin, token individual, etc.), ramas restauradoras, conexiones muertas y jerarquizaciones.
La aplicacin de las redes tambin se ha diversificado. Actualmente se utilizan para modelar
hardware, protocolos de comunicacin, programas paralelos, bases de datos distribuidas, sistemas de
control, productivos, de informacin, workflow, de procesos de negocio, etc.
Es debido a este desarrollo y amplia aplicabilidad, que se desea construir una primera versin de
una herramienta bsica para simular redes de Petri seguras de la clase condicin/evento, es decir, entendiendo la red compuesta por lugares, conexiones, arcos y anotaciones, y a la cual se le aplican reglas
de funcionamiento que permiten cambios de marcacin.
2 Herramienta a ser modelada
La herramienta se denominar SimPetri (acrnimo de Simulacin de redes de Petri) y debe
permitir simular redes de Petri en modo batch, en modo interactivo o en una combinacin de los mismos.
En el modo batch, el modelo de la red de Petri puede cargarse por medio de un archivo en formato XML34, que define los lugares, conexiones, arcos, anotaciones, la marcacin inicial y, opcionalmente, los carriles 35. Otro archivo contiene una secuencia de eventos a simular 36 y otros parmetros de
simulacin. Si el usuario lo pide explcitamente, la red puede ser desplegada en pantalla 37 con la marcacin inicial, y SimPetri aplica la secuencia de eventos para ver los cambios de marcacin. Entre los
parmetros de simulacin est la opcin de mostrar cada paso por un determinado intervalo de tiempo,
o slo entregar la marcacin final. En este modo batch, SimPetri genera a pedido del usuario, un archivo con la lista de todas las marcaciones alcanzadas.

34
35
36
37

eXtensible Markup Language. Todos los archivos que utiliza SimPetri siguen este formato.
Para el uso en los ciclos de vida de las entidades dinmicas.
Los eventos pueden definirse en secuencia y en paralelo.
Por el momento, no interesa modelar la interfaz grfica de la herramienta.

54

En el modo interactivo, el usuario puede construir una red ingresando grficamente todos los
elementos, as como la marcacin inicial. SimPetri indica todas las alteraciones habilitadas y el usuario
puede ir indicando qu eventos van ocurriendo y observar los cambios de marcacin (el usuario puede
configurar la simulacin en SimPetri con intervalos de tiempo para los pasos). La red puede guardarse
en un archivo en cualquier momento, con la marcacin correspondiente.
Ambos modos se combinan en la prctica, ya que se pueden cargar modelos guardados y usarlos
interactivamente, generar archivos de marcaciones de un modelo interactivo, guardar en archivos modelos creados interactivamente, etc.
SimPetri debe tener adems una funcin de verificacin de errores del modelo, para detectar
situaciones como lugares aislados y otros tipos de errores que debe definir el grupo de modelamiento.
Los errores deben ser comunicados al usuario interactivo, o agregados en el archivo de salida de marcaciones alcanzadas. Un modelo con problemas de consistencia puede simularse, pero tomando cuidado en el manejo de las situaciones de error.
En esta primera versin de la herramienta, se omitir la simulacin de acciones y condiciones en
la red, pero se deber incluir su representacin en el modelo esttico, para poder simularlas, sin alterar
este modelo, en la segunda versin de SimPetri.
Finalmente, SimPetri debe entregar las siguientes estadsticas del modelo de trabajo:

N de lugares con nombre de estado, sin nombre de estado, totales y porcentajes correspondientes
N de conexiones con evento, sin evento, totales y porcentajes correspondientes
N de conexiones con acciones, con condiciones, totales y porcentajes correspondientes
N de ramas alteradoras, restauradoras, totales y porcentajes correspondientes
N de carriles
N de lugares y conexiones totales por carril

37) Problema del Sistema DIDELCO para modelamiento en grupo:


1 Antecedentes
La empresa familiar DIDELCO (DIstribuidora DEL COmercio) ofrece productos varios, pero
principalmente alimenticios tales como arroz, azcar, t, galletas, fsforos, fideos y servilletas a pequeos negocios de barrio y minimarkets. Para esto cuenta con ms de 100 vendedores en todo el pas, que
atienden su variada clientela.
Actualmente, se est planteando reactivar la denominada ficha de visita, que se dej de usar en
2001, para suplir la actual carencia de informacin del rea de ventas. La ficha de visita es el resultado
de la iniciativa conjunta entre el Departamento de Sistemas y la filial de ventas de Santiago en el ao
2001, con el propsito de mejorar la informacin destinada a los vendedores. Hasta ese momento, el
vendedor dispona de datos estandarizados y actualizados, cubriendo varios aspectos de las ventas. A
pesar del arsenal burocrtico que transportaba (fichas circuito, tablas de precios, talonario de pedidos,
copias de facturas, informe diario de ventas, polticas de ventas, entre otros), el vendedor no posea
informacin bsica para su trabajo: el estado de los pedidos realizados, la situacin de crdito de sus
clientes, la programacin de presentaciones de productos, la eficiencia de la fuerza de ventas, etc.
55

Para tener una idea de la situacin del vendedor, basta describir la ficha circuito, su principal
instrumento de trabajo. Las fichas circuito eran grandes fichas de cartulina pre-impresas rotuladas con
etiquetas de clientes. En esta ficha el vendedor mantena todo el histrico de ventas, stocks y datos relevantes del cliente. Es fcil imaginar el estado fsico en que estas fichas quedaban despus de algn
tiempo de uso, y el trabajo de transcribir los datos de fichas antiguas a nuevas. Adems, las fichas circuito registraban slo datos elementales levantados por el propio vendedor que, si usados aisladamente,
poco contribuan al contexto global de ventas.
La situacin del vendedor se complicaba ms al tener que lidiar con algunos clientes que tenan
sistemas informatizados. El vendedor se vea en problemas, psimos para la imagen y credibilidad de la
empresa, cuando se le preguntaba por informacin que no tena.
En el segundo semestre de 2001, la ficha de visita fue implantada, visando revertir el cuadro
existente y establecer una prctica sana de ventas. Se sustituy gradualmente las fichas circuito de los
vendedores de la filial de Santiago, de tal manera que al llegar el 2002, se logr la total implantacin de
la ficha de visita. En el primer semestre de 2002, se decidi extender la utilizacin de la ficha de visita
a las filiales de venta del resto del pas, donde los resultados no fueron tan satisfactorios como los obtenidos en Santiago. La principal falla de esta implantacin se debi a problemas operacionales, en la
mantencin centralizada automatizada de las fichas de visita, con lo cual se volvi al esquema de ventas anterior a 2001, el cual todava se mantiene.
La informacin que el vendedor recibe, la prctica de ventas y las necesidades son las mismas
de 2001. El vendedor se dej al margen del desarrollo informacional que la empresa experiment en los
ltimos aos y que, adems de los problemas prcticos, se est poniendo en juego el futuro de la participacin de mercado, que depende cada vez ms de quien tiene la informacin.
2 Sistema de Informacin a Ser Modelado
El sistema de informacin debe permitir generar y mantener la ficha de visitas y permitir la subida/descarga de las mismas por parte de los vendedores.
La estructura de la ficha de visitas fue establecida a partir de los procesos adoptados en la filial
de ventas de Santiago. Cada vendedor posee, en su zona de ventas, determinado nmero de locales a
ser visitados al mes. Los locales estn distribuidos en sectores de ventas que poseen periodos de visita
mltiplos de 7 das, es decir, periodos semanales, quincenales y mensuales. La composicin de la ruta
de visitas se hace por la combinacin de sectores, de forma de cubrir todos los das del mes. Por ejemplo, si los sectores 1 y 2 son semanales, los sectores 3, 4, 5 y 6 son quincenales y los sectores 7, 8, 9 y
10 son mensuales, el esquema de visitas sera:
lu
1

1 semana
ma mi ju
2
3
4

vi
7

lu
1

2 semana
ma mi ju
2
5
6

vi
8

lu
1

3 semana
ma mi ju
2
3
4

vi
9

lu
1

4 semana
ma mi ju
2
5
6

vi
10

A partir de la fecha de la visita y del periodo de visita -registrados por el vendedor para cada
sector-, el sistema se encarga de generar automticamente las fichas de forma a cumplir el esquema
propuesto, siempre utilizando los datos ms recientes.

56

La ficha de visita est subdividida en 4 bloques de datos:

Datos generales sobre el cliente: nombre y direccin del cliente, direccin para cobranza,
RUT, tipo de cobranza, nombre del banco para cobranza (si corresponde), horario de visita,
condicin de entrega, da de la semana para entrega, periodo de la visita, estado del cliente (activo, cancelado, bloqueado), rubro, condiciones de pago, contacto en el cliente, e-mail y telfono.

Situacin financiera resumida: lmite de crdito del cliente, total vencido, total por vencer y
disponibilidad de crdito.

Histrico de ventas: descripcin del producto, cdigo del producto, cuadros () para ingresar
cantidad, precio unitario, descuento y stock del cliente; precio promedio practicado y promedio
de ventas por producto en los ltimos 6 meses, 4 ltimos periodos de venta mostrando datos del
stock del cliente, la venta realizada y el histrico de atencin del pedido (pedido atendido, pedido pendiente, pedido cancelado, pedido con programacin de entrega futura, entrega parcial,
cancelamiento por reemplazo).
Situacin financiera detallada: copias de facturas vencidas y por vencer con N, fecha de emisin, fecha de vencimiento, monto total y das de atraso (para las vencidas).

Los datos generales describen bsicamente al cliente. La situacin financiera resumida es justamente el resumen consolidado de los datos sobre la cuenta corriente del cliente. Se trata de informacin objetiva y de suma importancia para el vendedor, que toma conocimiento de la situacin financiera del cliente frente a la empresa, ayudndolo en la decisin respecto de ventas futuras. El histrico
de ventas mantiene informacin sobre las ltimas ventas efectuadas. Se trata de un bloque que apoya
al vendedor para realizar su trabajo en forma ms racional y objetiva. La situacin financiera detallada
entrega al vendedor las condiciones para discutir sobre el cliente frente a la empresa, adems de aclarar dudas sobre la cobranza.
Con la implantacin de la ficha de visita, el talonario de pedidos se descarta, ya que los datos
del pedido y del stock del local sern realizados en la propia ficha, que se propone est disponible en
netbooks o subnotebooks de los vendedores. Estos datos deben ser transferidos a la central, va Internet,
una vez al da. As como el vendedor debe recibir diariamente las fichas de visitas actualizadas de sus
clientes.

38) Problema del Sistema Herramienta SimProNe para modelamiento en grupo:


1 Antecedentes
Se ha afirmado que el Diagrama de Actividades (DAct) fue una de las sorpresas del lenguaje
estndar UML. A diferencia de otros diagramas, no exista ningn precedente en el trabajo previo de
los autores originales de este estndar. El DAct fue concebido como un modelo hbrido que combina
ideas de varias tcnicas como los diagramas de eventos de J. Odell, el modelamiento de estados de
SDL (Specification and Description Language) y las redes de Petri.
El DAct es particularmente til para representar flujo de trabajo (workflow) y para describir
comportamiento con procesamiento paralelo. Las actividades en un DAct pueden representar desde una
tarea que debe realizar una persona o un computador en un procedimiento, hasta un mtodo de una clase, dependiendo de la perspectiva conceptual o de implementacin con que se construya el diagrama.
57

Una aplicacin frecuentemente utilizada es la representacin de la lgica interna de realizacin


de los procesos de negocio de una organizacin. El DAct puede mostrar la organizacin temporal de
estas actividades y las responsabilidades involucradas en la generacin de valor de un proceso de negocio. Este diagrama se ha convertido en un importante antecedente para el estndar ms reciente BPMN
(Business Process Modeling Notation), que est diseado especficamente para este propsito.
Considerando este tipo de aplicaciones, es que se propone una primera versin de un simulador
de procesos de negocio, basado en DAct que permita por una parte, representar la lgica de los procesos de negocio, y por la otra, aportando informacin cuantitativa sobre las actividades que lo componen, estimar la duracin de la realizacin del proceso para que el usuario pueda evaluar su funcionamiento.
2 Herramienta a ser modelada
La herramienta se denominar SimProNe (Simulador de Procesos de Negocio) y debe permitir
representar, en esta versin preliminar, actividades, nodos inicial y final, transiciones entre actividades,
nodos de decisin/unin y nodos fork/join, como elementos bsicos, y carriles unidimensionales, flujo
de objetos y conectores como elementos avanzados. Otros aspectos, como la jerarquizacin o el nodo
de trmino de flujo por ejemplo, no sern tratados hasta una prxima versin.
El usuario puede crear o modificar varios proyectos, que consisten en uno o ms diagramas de
proceso. No interesa la interfaz grfica de SimProNe 38, sino que permita administrar todos los elementos bsicos y avanzados del diagrama, almacenndolos y asegurando la consistencia lgica de los modelos construidos. Por ejemplo, debiera reconocer que no es posible que un nodo join est despus de
un nodo de decisin, o que no puede haber un nodo final a seguir de un nodo inicial. Si el usuario ingresa este tipo de relaciones, SimProNe debe indicarle que constituyen un error.
SimProNe, adems de permitir el manejo los proyectos, tiene la opcin de cuantificar los procesos modelados. La simulacin en esta versin preliminar es extremadamente simple: se asume que la
duracin de las actividades sigue una distribucin de probabilidad , similar a la utilizada en el mtodo PERT (Program Evaluation and Review Technique) 39. Para este fin, el usuario debe ingresar, para
cada actividad de un diagrama de proceso, los siguientes tiempos:
tiempo optimista (to) = duracin ms breve posible, suponiendo que todo funciona bien en la
realizacin de la actividad, es decir, es el mejor escenario posible (cota inferior de la distribucin de probabilidad),
tiempo pesimista (tp) = duracin ms extensa posible, suponiendo que ocurren problemas que
dificultan y alargan la realizacin de la actividad, es decir, es el peor escenario posible (cota superior de la distribucin de probabilidad), y
tiempo normal (tn) = duracin ms probable de realizacin de la actividad, suponiendo slo contratiempos comunes, es decir, es el escenario ms frecuente (moda de la distribucin de probabilidad).

38

Se puede asumir una interfaz semejante al de la herramienta Visual Paradigm para UML.
En una prxima versin se podr seleccionar distribuciones de probabilidad y sus parmetros correspondientes,
tales como la uniforme, triangular o normal, por ejemplo.

39

58

Con los valores de estos 3 tiempos es posible determinar el tiempo esperado (te) de duracin de
cada actividad de acuerdo a la siguiente frmula:
t p + 4t n + to
te =
6
Contando con los tiempos esperados de todas las actividades de un proceso, SimProNe puede
calcular determinsticamente la duracin estimada del proceso, atendiendo la organizacin temporal
que tienen dichas actividades en el diagrama de proceso. Para esto debe sumar los tiempos de las actividades del camino crtico, tomando los hilos excluyentes y paralelos de mayor duracin en cada nodo
de decisin/unin y fork/join, y entregar al usuario esta estimacin asociada al diagrama del proceso.
Finalmente, el usuario puede experimentar con el modelo del proceso, introduciendo los cambios que estime convenientes, tales como la modificacin de transiciones, la paralelizacin de actividades, la eliminacin de decisiones o el cambio de los tiempos de las actividades, entre otros, y ver qu
sucede con la duracin estimada del proceso en cada caso. Para esto SimProNe le debe ofrecer la opcin de generar y guardar diferentes versiones del modelo de un proceso, para que el usuario pueda
hacer evaluaciones, contrastando la versin vs. la duracin estimada del proceso.

39) Problema del Sistema Arrauto para modelamiento en grupo:


1 Antecedentes
El negocio de arriendo de vehculos para empresas y turistas ha crecido de forma importante en
estos aos. La anteriormente pequea empresa familiar Arrauto ha incorporado nuevos socios y se ha
propuesto crecer significativamente, abriendo sucursales en la principales ciudades del pas. Estn al
tanto que esto significa competir con empresas multinacionales que tienen procesos y sistemas world
class.
Una de las fortalezas de la empresa es una clara definicin y cumplimientos de sus procesos
internos y una excelente satisfaccin de sus clientes. Como hasta ahora opera slo en la ciudad de Via
del Mar, sus dueos centralizan el manejo de informacin. Los procesos utilizan planillas electrnicas
con algunas macros desarrolladas especialmente. Estn conscientes de que esta forma de operar no es la
ms adecuada para la estrategia de crecimiento. Por esto se han propuesto construir un sistema de informacin que permita mantener la informacin de la reserva y cobranza del arriendo de vehculos y de
esta manera enfrentar de mejor manera el desafo de crecer.
2 Sistema a ser modelado
El sistema debe soportar los siguientes requerimientos establecidos a partir de los procesos de
Arrauto:
Los vehculos pueden ser retirados en un local y ser devueltos en otro, aunque en general es ms
frecuente que sean retirados y devueltos en el mismo local. Todos los vehculos son entregados
con el estanque lleno de combustible y debe ser devueltos en esta misma condicin.
Los diferentes modelos de vehculos son agrupados en categoras que tienen diferentes tarifas.
Existen planes especiales de arriendo con tarifas rebajadas, especialmente para fines de semanas
y feriados en general, de modo a atraer a clientes particulares (no empresas).
A las empresas se les ofrece un contrato donde se establece las condiciones del nmero de vehculos, categoras, equipos, kilometrajes, locales y tarifas especficas.
59

Existen 2 planes estndares de arriendo:


1. Una tasa fija diaria bsica (por categora de vehculo) ms un valor calculado en funcin
del kilometraje recorrido dependiendo de la categora del vehculo.
2. Una tasa fija diaria normal (tambin por categora de vehculo), independiente del kilometraje recorrido.
Los clientes pueden escoger libremente, sin recargos, automviles 2x4 4x4, fumadores o no
fumadores, y manual o automtico. Equipos adicionales tienen recargos diarios especficos:
rack para equipaje, remolque, asientos para nios y navegador satelital.
Todos los vehculos tienen adems un recargo por seguro estndar diario, que depende de la categora. Estos seguros estn contratados con diversas compaas. Todos los aos ocurre algn
cambio en las aseguradoras.
Los arriendos duran 24 horas, con una hora de holgura sin recargo adicional de tarifa diaria.
Un atraso de 6 o ms horas corresponde a 24 horas adicionales. Por ejemplo, sin un cliente retira un vehculo a las 9:00 del da 1 y lo retorna hasta las 10:00 del da 3, slo tiene 2 diarias; si lo
retorna hasta las 15:00, se le cobra 2 tarifas diarias; y si lo retorna despus de las 15:00, se le
cobra 3 tarifas diarias.
Los clientes pueden arrendar un vehculo disponible o hacer reservas con anticipacin. Las 2
categoras ms bsicas de vehculos no requieren dejar ningn tipo de garanta, y se espera al
cliente 60 minutos despus de la hora comprometida, disponibilizando el vehculo despus de
este plazo. En las otras categoras, la reserva dura 24 horas equivalente al monto cargado como
garanta (se carga slo la tasa fija diaria bsica ms equipos), si es que el cliente no utiliza el
vehculo.
Finalmente, el sistema debe generar algunos reportes tiles para la gerencia:

1. Uso de vehculos: cada vehculo con los tiempos disponible/arrendado y los kilometrajes, ordenados de mayor uso al menor, para cualquier periodo que se indique.
2. Entregas de vehculos: cada vehculo con las entregas a tiempo/atrasada, dentro de cualquier periodo indicado.
3. Venta de planes: resumen de los planes vendidos estndares y los especficos de contratos, en
periodos mensuales.

40) Problema del Sistema CRPas para modelamiento en grupo:


1 Antecedentes
Una pequea y nueva compaa area Cernicaline (se pronuncia cer-n-ca-lain) se ha ganado
una licitacin para atender a un localidad minera en crecimiento en el norte del pas. Las personas de
esta localidad que pretenden viajar tendrn ahora diversas opciones en vuelos atendidos por Cernicaline
que realiza vuelos desde/hasta la localidad.
Para esto, la compaa se ha propuesto disear y construir una primera versin de un sistema
propio de control de reservas de pasajes areos, denominado CRPas.

60

2 Sistema a ser modelado


La reserva de pasajes se har descentralizada, definindose un local en el propio aeropuerto y
otro en el centro de la localidad. Los dos puntos de reserva deben estar interconectados. Para efectuar
una reserva, el cliente se debe identificar, proporcionando al empleado de Cernicaline su cdula de
identidad. Este empleado hace el pedido de reserva para determinado vuelo (destino, fecha, hora, modalidad de vuelo). Las modalidades de vuelo posibles son 1 clase y turista. Cada reserva tendr un
lmite de validez asociado, como mximo hasta 24 horas antes del vuelo solicitado. Durante este plazo,
la reserva permanecer asignada a este pasajero. Si no hay confirmacin (que implica el pago y retiro
del pasaje por parte del pasajero en uno de los locales) hasta el lmite indicado, el pasajero pierde la
reserva, aumentndose el nmero de disponibles en el vuelo.
El pago es hecho en el momento de la confirmacin de la reserva por el pasajero, que recibe
entonces su pasaje (ticket). En el caso de que el pasajero solicite reserva en un vuelo con disponibilidad
agotada, el empleado debe incluir el nombre y contacto del solicitante en una lista de espera del vuelo,
que puede soportar un mximo de 20 pedidos de reserva. A medida que los pasajeros desisten de sus
reservas, se llama a los solicitantes que integran la lista de espera, por orden de inclusin. Una vez avisados de la existencia de disponibilidad en un vuelo, los clientes hacen su reserva, retomndose el proceso normal.
Tambin es posible que ocurran desistencias de pasajeros que ya confirmaron sus reservas. Estos pasajeros, si lo hacen hasta media hora antes del embarque, podrn solicitar un asiento en otro vuelo. En cualquier caso, la desistencia implica en el aumento de disponibles en el vuelo.
Dos horas antes de la hora del vuelo, se inicia el proceso de recepcin de equipaje y la emisin
de la autorizacin de embarque, en el mesn del aeropuerto. Si el pasajero no se presenta en el mesn
hasta media hora antes del vuelo, aunque no haya desistido formalmente, pierde el derecho al pasaje y
su asiento en el vuelo ser ofrecida al prximo en la lista de espera que est presente en el aeropuerto.
Como poltica, la compaa deja siempre dos asientos libres hasta la hora del embarque, para la atencin de eventuales pedidos de emergencia. Estos pedidos deben ser visados por el jefe de aeropuerto de
Cernicaline. Estos asientos pueden ser llenados tambin por la lista de espera, caso no se utilicen por
emergencia.
Despus de haber sido realizadas las ltimas alteraciones de las reservas cuando ocurre la ltima
llamada de embarque, el sistema debe elaborar el registro del vuelo, que contiene datos (nombre, RUT
y asiento) de todos los pasajeros que efectivamente viajarn.
El sistema debe considerar la actualizacin permanente del registro de vuelos de cada da, por el
plazo de un ao a partir de su realizacin.
Finalmente, el sistema deber emitir:

El registro de cada vuelo, con emisin antes de la autorizacin para el despegue, con copias al
controlador del aeropuerto, al comandante de la aeronave y al Depto. de Contabilidad de la
compaa.
Un informe contable, con los totales ingresados en cada vuelo, emitido cada 24 horas para el
Depto. de Contabilidad.

61

Estadsticas mensuales de uso de disponibilidades de los diversos vuelos, para el Depto. de Planificacin de Cernicaline.

41) Problema del Sistema TeleGSM para modelamiento en grupo:


1 Antecedentes
La compaa de Telefona celular Global System for Mobile communications (TeleGSM) ofrece
equipos telefnicos inalmbricos y servicios relacionados para sus clientes. Para poder competir con las
grandes compaas internacionales ha introducido el concepto de la portabilidad fija-mvil. En una
primera etapa, permite al cliente utilizar su nmero de telefona fija para un celular. Futuramente, la
compaa ofrecer un nico aparato que utilice las redes fija y mvil: cuando est fuera del hogar, por
ejemplo, operar como cualquier telfono celular, pero cuando colocado sobre la base del hogar, se
cambiar a la red fija, bajando significativamente los costos para el cliente.
Para ofrecer sus productos, TeleGSM debe desarrollar un sistema de informacin de apoyo a los
procesos medulares.
2 Sistema a ser modelado
Los telfonos de TeleGSM son empaquetados para la venta, en la forma de un kit de distribucin de pre-venta en el centro de ensamblado de productos de la compaa. Cada kit consiste principalmente de un aparato telefnico y una tarjeta SIM (Subscriber Identity Module). El fabricante asigna
a cada aparato telefnico un nmero nico denominado IMEI (International Mobile-communications
Equipment Identifier).
Una persona puede perfectamente tener ms de un SIM, pero debe tener a lo menos un SIM
para ser considerado un cliente. Un cliente puede tener ms de un aparato telefnico, sin embargo no es
un requisito para ser cliente. La tarjeta SIM es intercambiable entre varios modelos de equipos telefnicos vendidos por la compaa. En la prctica, la gran mayora de los clientes posee al menos un equipo
telefnico. Con la compra de un kit inicial, algunos clientes optan por mejorar su equipo a un modelo
ms pequeo, liviano o con mayores funcionalidades.
En el back office, la compaa mantiene un inventario de nmero telefnicos disponibles para
mviles. Para facilitar el paso de telefona fija a mvil, la compaa ofrece asignar el nmero convencional (incluyendo el cdigo de rea) de telefona fija al MIN (Mobil Identification Number) para algunos de sus planes. Finalmente, cada MIN nico, independiente si se origina en un nmero fijo o no,
ser asociado con una tarjeta SIM de un cliente especfico, cuando una nueva cuenta se activa. Un
nmero IMSI (International Mobile SIM Identifier) identifica cada SIM.
Para los propsitos de facturacin, la compaa mantiene un registro de cada evento CDN (Call
Delivery Notification) y su duracin, asociado con el IMSI al cual facturar. El primer da hbil del mes,
se facturan todos los eventos CDN del mes recin pasado y su correspondiente tarifa de acuerdo al plan
contratado.

62

Los planes son dinmicos y sujetos a muchas ofertas, por lo que no basta con conocer el plan,
sino que tambin el precio que tena a la fecha en que el cliente lo suscribi. Al 26/11/2010, TeleGSM
ofrece 5 planes segn la tabla siguiente.
Plan
Minutos incluidos
Bsico
100
Medio
300
Full
500
Fijo compatible
350
Ilimitado
0

Monto fijo Monto/min adicional


$12.900
$89
$19.900
$79
$29.900
$49
$24.900
$79
$39.900
$0

Adems, dentro del mes, un cliente puede cambiar de plan, cobrndose el monto fijo de los planes de forma proporcional al nmero de das del mes (28, 29, 30 y 31). Por ejemplo, si un cliente tiene
el plan bsico del 1 al 20 de octubre y a partir del 21 de octubre se cambia al plan medio, con una promocin de 15% de descuento ($16.915), se le debe facturar en noviembre un monto fijo de
$12.990*20/31 + $16.915*11/31 = $14.325 ms el consumo adicional, por sobre los minutos incluidos
en cada plan, segn la vigencia correspondiente.
El sistema debe permitir crear, consultar, actualizar y eliminar cualquier cuenta de cliente. Esto
incluye el cambio de SIM, equipo, plan, etc., as como los datos personales del cliente.
Adems, el sistema debe ofrecer informacin sobre el comportamiento global de los clientes
respecto a los planes que contratan. Debe mostrar reportes con tiempos de permanencia en los planes,
los porcentajes de cambios entre planes, los planes de clientes entrantes y salientes, etc 40. Todo esto
con base mensual y anual.

42) Problema del Sistema MediClin para modelamiento en grupo:


1 Antecedentes
La clnica MediClin comenz en 1998 como una sociedad familiar de profesionales: un to, dos
hermanos y un primo, todos mdicos de diversas especialidades. Esta clnica comenz a crecer y en
2003 se decidi contratar los servicios de otros mdicos. La excelente atencin personalizada que ofrecen ha tenido buena recepcin en el mercado, y la demanda sigue aumentando. Antes de se produjera
una crisis de crecimiento, los socios decidieron contratar a una pequea empresa consultora para que
les propusieran procesos estandarizados y mejorados de servicio a sus pacientes.
Entre los procesos considerados est el de atencin mdica a los pacientes. La propuesta de la
consultora ha establecido la necesidad de contar con un sistema de informacin de apoyo a la operacin
de este proceso en los trminos indicados a continuacin.
2 Sistema a ser modelado
Los mdicos ofrecern a su secretaria, de tiempo en tiempo, distintas disponibilidades de atencin para las semanas o meses siguientes, de acuerdo a sus horarios especficos. La secretaria deber
ingresar estas disponibilidades en el sistema.
40

Se deber proponer al menos un reporte adicional que sea til para la gestin de los planes de suscripcin de TeleGSM.

63

Por otra parte, habr una operadora telefnica que recibir las llamadas de los pacientes y, de
haber disponibilidad de acuerdo a las necesidades de los mismos, reservar una hora con el mdico de
la especialidad que requiere, tomndosele sus datos (o los confirma, si ya se atendi antes): RUT, nombre, edad, sexo, forma de contacto (telfono fijo, celular o correo electrnico) y tipo de previsin (particular, convenio, FONASA, Isapre, otra) e informndole que se le pedir posteriormente una confirmacin . El sistema deber solicitar expresamente a la operadora telefnica que confirme la consulta
con los pacientes, medio da hbil antes de cada hora reservada. Las horas que no puedan ser confirmadas quedarn disponibles.
Llegada la hora de atencin, la secretaria deber registrar en el sistema, las horas de entrada y
salida de las consultas con el mdico, para cada paciente que efectivamente acuda.
Ante la eventualidad del cambio de horario de un mdico, ste informar a su secretaria, quien
realizar los cambios en el sistema e informar a la operadora para que reprograme las reservas afectadas, si las hay.
Al trmino de cada mes, la secretaria solicitar un completo informe de consultas para la Gerencia, que indique, para cada mdico que atiende en la clnica, la cantidad de horas de atencin ofrecidas/efectivas, el promedio de duracin de sus atenciones y el nmero de reservas modificadas producto
de cambios. Adems, deber incluir la cantidad y porcentajes globales de:
llamadas que consiguieron/no consiguieron reserva,
reservas que fueron/no fueron confirmadas
atenciones que ocurrieron/no ocurrieron

43) Problema del Sistema CDResurrection para modelamiento en grupo:


1 Antecedentes
Todos tenemos en algn cajn un CD antiguo que ya no escuchamos, pero que podra ser del
gusto de otras personas. Bajo esta premisa, un grupo de emprendedores ha decidido iniciar un negocio
de compra y venta de CD y DVD comenzando en Chile, pero con intencin de alcanzar rpidamente el
mercado latinoamericano.
La idea bsica es comprar los CD o DVD de las personas y luego colocarlos en un catlogo en
lnea, para que estn ampliamente disponibles para la venta. El equipo creativo ha decidido denominar
a este negocio CDResurrection, ya que es una sobrevida para los CD o DVD que moriran sin ser escuchados o vistos.
2 Sistema a ser modelado
Para comprar los CD y DVD a clientes vendedores, en una fase inicial, se ha decidido utilizar
los catlogos con la identificacin de CD y DVD, de los sellos nacionales y de las multinacionales en
Latino Amrica. Esto permite conocer qu se ha publicado en estos formatos y as el cliente vendedor
puede buscar por nombre del artista (visualizando todos sus obras), por ttulo o por cdigo de barras (el
cliente puede usar un dispositivo o digitar el cdigo). Una vez identificado, el sistema le indica el precio de compra ofrecido.
64

El sistema calcula el precio de compra en funcin del stock disponible del ttulo, de la rotacin
y de la demanda que ha registrado, si ste no se encuentra disponible. Todos los ttulos simples de CD
y DVD tienen un precio de compra equivalente a dos dlares. Si la rotacin es baja (menos de cuatro
unidades compradas-vendidas en 30 das), tiene un descuento de 25%. Si la rotacin es alta (ms de 10
en 30 das), se incrementa en 50%. Si el stock es alto (ms de 10 unidades), tiene un descuento de 50%.
Si el stock es bajo (menos de tres unidades, pero no cero), se incrementa en 25%. Si el stock es nulo, se
considera la demanda por el ttulo, contando las consultas que clientes compradores hacen por el ttulo
desde que est sin stock. Se incrementa el precio segn 10% por cada consulta diaria hecha en promedio. Ejemplos de fijacin de precios de compra:
1. Un ttulo con una rotacin de tres, con 15 unidades en stock, tendra un precio de US$ 0,50 =
2,00 (25% de 2,00) (50% de 2,00)
2. Un ttulo con rotacin 12, con dos unidades en stock, tendra un precio de US$ 3,50 = 2,00 +
(50% de 2,00) + (25% de 2,00)
3. Un ttulo con rotacin seis, sin stock y con un promedio de tres consultas diarias de clientes
compradores, tendra un precio de US$ 2,60 = 2,00 + 3 * (10% de 2,00)
Una vez el cliente acepta los precios de compra y decide vender, se le entregan las instrucciones
para que despache los productos e indica si quiere el dinero depositado en una cuenta o como crdito a
su favor en la cuenta de CDResurrection. El Departamento de Finanzas realiza la transaccin y valida
el crdito que queda pendiente hasta la recepcin de su despacho. Cuando se recibe la encomienda del
cliente se verifica el estado de los productos y si son aprobados, se informa a Finanzas para que libere
el crdito.
El precio de venta de un CD es calculado simplemente multiplicando por tres el precio de compra. As entonces, el precio estndar de venta es equivalente a seis dlares (los precios para los tres
ejemplos anteriores seran, respectivamente, US$ 1,50, US$ 10,50 y US$ 7,80).
A todos los pedidos se les cobra un cargo por flete. Dentro de Chile, el cargo fijo es de US$
3,00; dentro de Amrica del Sur es US$ 6,00 y de US$ 10,00 para el resto del mundo.
Una vez que el cliente ha decidido comprar los productos, lo confirma en el sistema e indica la
forma de pago, que puede ser contra crdito disponible en su cuenta en CDResurrection (por ejemplo si
antes vendi CD/DVD) y/o con tarjeta de crdito o va Pay Pal. En estos ltimos casos, el pago lo realiza el cliente directamente en los sistemas propietarios de estos medios. Con la confirmacin del pago
(y/o uso del crdito), se rebaja el stock, se separa el pedido y se le despacha a la direccin registrada.
Todos los parmetros indicados, tales como los precios de compra (simples, dobles, etc.), porcentajes de descuento e incremento, rangos de rotacin, cantidades en stock, factores multiplicativos
para precios de venta y valores de flete, entre otros, deben poder ser modificados por usuarios expresamente autorizados para el efecto.
El Departamento de Marketing de CDResurrection plantea frecuentemente ofertas a los clientes,
vlidas por algunos das. La modalidad es ofrecer un cdigo que el cliente debe digitar y solicitar aplicar al momento que se le calcula el total. Estas ofertas se publican en la pgina principal del sitio y son
enviadas por correo electrnico y/o twitter a los clientes registrados que han indicado que le interesa
recibir esta informacin por dichos medios. Las ofertas son tanto para compras como para ventas. Un

65

ejemplo tpico de ofertas de compra es un 20% ms por cada CD si vende 10 o ms unidades. Existe
mayor variabilidad de ofertas para ventas, por ejemplo:
Flete gratuito
Pague 3 CD/DVD y lleve 4 (el de menor precio es gratis)
20% de descuento, si compra US$ 30,00 o ms
25% de descuento y flete gratuito, si compra US$100,00 en el da indicado
Tambin se realizan ofertas a perfiles de clientes de inters para CDResurrection. Por ejemplo,
existe un bono equivalente a US$ 10,00 para los clientes compradores que alcancen los US$ 500,00 en
compras en un ao calendario, o se le ofrece un bono de 25% de descuento en compras a cliente vendedores que hayan vendido ms de 100 ttulos en un ao calendario. Estos bonos deben ser validados,
tanto respecto del periodo de aplicacin como de los clientes que correspondan. Tambin hay bonos
especficos para un nico cliente en ocasiones especiales, que son autorizados por el Jefe de Operaciones, por ejemplo cuando se quiere compensar de alguna forma a un cliente a quien se le han despachado ttulos equivocados o daados o incompletos, o cuando se ofrecen ofertas a clientes en la semana de
su cumpleaos.
Tambin se ha diseado ofrecer otros dos servicios. Llevando el registro de todos los pedidos
que haya realizado un cliente como comprador, se le puede indicar los 10 ttulos que haya comprado
que tengan el mayor precio de compra. De esta forma l puede considerar revenderlos a CDResurrection. El otro servicio es que el cliente comprador puede construir una wish list, es decir, una lista con
los ttulos que le gustara comprar y revisarlos siempre que quiera. Con esto puede descubrir ttulos que
anda buscando, cuando alguien los haya vendido a CDResurrection. Esto tambin puede notificarse, si
el cliente as lo pide, con un correo electrnico o por twitter.
Finalmente, el Departamento de Marketing requiere reportes para definir las ofertas y determinar su efectividad, entre los que se pueden mencionar:
Clientes que ms compran
Clientes que ms venden
Clientes con wish list ms extensos
Ttulos con mayor rotacin
Ttulos con mayor aumento o disminucin de rotacin
Ttulos con mayor stock

44) Problema del Sistema Charly 3 Vigilancia para modelamiento en grupo:


1 Antecedentes
Charly 3 Vigilancia S.A. es una pequea empresa que se dedica a la instalacin, mantenimiento
y utilizacin de dispositivos para la vigilancia de inmuebles particulares y de empresas. Recientemente
ha logrado un excepcional contrato que le permitir crecer de forma importante: ser el nico proveedor para planificar y realizar la vigilancia de varios condominios en construccin en Curauma. Si todo
funciona bien, este contrato le permitir al menos cuadruplicar su clientela en un plazo de seis aos.
Para hacer frente de buena forma a este crecimiento en la demanda de sus servicios, la empresa
Charly 3 debe realizar la instalacin y monitoreo de sensores a diferentes tipos de accesos indebidos

66

que se pueden producir en cada casa de los condominios.


2 Sistema a ser modelado
La empresa Charly 3 requiere un sistema que considere seales producidas por los siguientes
dispositivos detectores:
Irrupciones: Corresponden a aperturas no autorizadas (obviamente siempre y cuando el sistema
de alarma se encuentre activado) de cualquier puerta o ventana que comunique la casa con el
exterior. Previendo de que una irrupcin se haya producido y no haya sido detectada por los
sensores, se podr instalar otros dispositivos interiores.
Accidentes: Corresponden a sensores que detectan accidentes que pueden producirse en una casa, tales como incendios e inundaciones.
Estos sensores est conectados a una caja de control de la casa y sus seales son enviadas y recibidas inalbricamente por el sistema en la central de monitoreo, que Charly 3 construy en Curauma.
Cada condominio posee uno o ms tipos de casa, que tienen la ubicacin de los sensores prediseada, pero finalmente cada propietario puede querer modificar o extender el diseo bsico de la casa.
Los sensores se van instalando a medida que los propietarios vayan recibiendo las llaves de sus casas.
En este caso, el propietario entrega una lista de usuarios autorizados para activar/desactivar las alarmas
de la casa con una contrasea, as como la informacin de contacto para verificar problemas de identificacin (por ejemplo cuando se digita ms de tres veces una contrasea incorrecta).
Para operar el sistema de la central, la empresa Charly 3 ha designado a un supervisor de alarmas como el responsable de la colocacin de los dispositivos fsicos en las diferentes ubicaciones de la
casa. Es decir, es quien se encarga de decidir qu alarmas se podrn disparar en cada una de las dependencias de la casa. Este supervisor es quien debe informar al sistema de los datos de usuarios, contactos
y contraseas para cada casa nueva, junto con los distintos dispositivos, su identificador de hardware y
su ubicacin.
Existe tambin supervisores de alarmas para atender en los turnos de maana (7:00 a 15:00),
tarde (15:00 a 23:00) y noche (23:00 a 7:00). Estos supervisores deben solucionar todas las peticiones
realizadas por los propietarios de las casas, ya sea respecto del mal funcionamiento de algn sensor,
cambio de ubicacin o problemas de comunicacin.
Los dispositivos fsicos, una vez instalados, envan peridicamente seales de funcionamiento
OK, funcionamiento comprometido y seales de activacin al sistema central. La sensibilidad de estos
dispositivos debe ser calibrada por un administrador en el sistema. El administrador adems determina
la o las acciones que se desencadenarn como consecuencia de la recepcin de una seal de un sensor
de una casa: activar una alarma sonora, llamar a Carabineros, llamar a Bomberos, llamar a urgencias de
ESVAL, pedir un furgn de vigilancia de Charly 3 para una inspeccin ocular o activar una alarma
visual. Se cuenta con administradores slo en los turnos de maana y tarde.
Por otra parte, los vigilantes son responsables de controlar la seguridad de las dependencias en
cada una de las casas con dispositivos instalados en un condominio. Pueden activar o desactivar todo el
sistema de alarma de una casa determinada. Ellos consultan continuamente el sistema de monitoreo de
las alarmas y slo dejan de hacerlo cuando tienen que hacer rondas de vigilancia. El sistema asigna

67

aleatoriamente, a cada vigilante, una ronda de inspeccin diaria en cada turno. Inicialmente existen tres
vigilantes asignados en cada turno de servicio. Terminada la ronda, cada vigilante debe actualizar una
bitcora en el sistema, que describa los hechos relevantes ocurridos en ella.
Por ltimo, los vigilantes tambin debern realizar las acciones indicadas por el administrador,
atendiendo debidamente una alarma, al realizar la finalizacin del aviso correspondiente. Esta tarea de
finalizacin deber desencadenar automticamente, pero de manera perceptible para el vigilante, la
reinicializacin de todos los dispositivos de alarma instalados en las dependencias de una casa. Tambin pueden realizar simulaciones de las alarmas, para probar que el sistema funciona correctamente en
una casa.
Los supervisores, administradores y vigilantes debern identificarse para ingresar al sistema,
con el rol correspondiente y una contrasea de seguridad, lo cual permite al sistema proporcionar las
funciones disponibles en cada caso.
Finalmente, el sistema debe emitir informes diarios sobre el estado de todas las casas monitoreadas por condominio, indicando las situaciones de alerta o mal funcionamiento. Adems, se debe
emitir un informe mensual para dar cuenta de la frecuencia de ocurrencia de situaciones de alerta, esta
informacin permite decidir si se debe reforzar rondas o asignar ms vigilantes.

45) Problema del Sistema de Deteccin de Infractores en Autopistas Concesionadas para modelamiento
en grupo:
1 Antecedentes
Con las autopistas concesionadas siendo una realidad muy comn en Chile hoy en da, ha surgido un problema importante: las infracciones por exceso de velocidad. Como la infraestructura de estas
autopistas no est concebida con bermas ni amplios ejes centrales, es difcil ubicar puntos de control
para personal de Carabineros, ni es tampoco lo ideal.
Una solucin tecnolgica que propone la Concesionaria VaLibre es aprovechar el registro del
paso de los vehculos identificados en cada prtico, determinando la velocidad promedio de circulacin
entre los mismos, detectando as a los infractores. Por ejemplo, si una autopista tiene definida una velocidad mxima de circulacin de 100 km/h, supngase dos prticos A y B separados por una distancia
conocida, por ejemplo 7.320 metros. Un vehculo determinado cruza el prtico A a las 11:46:19 y cruza
el prtico B a las 11:49:56. El sistema calcula entonces que el vehculo se desplaz a una velocidad
promedio de 7.320 m / (11:49:56 - 11:46:19) que equivale a 121,4 km/h, con lo cual se detecta una infraccin.
VaLibre, en asociacin con distintas instituciones pblicas, entre los cuales se encuentran las
Municipalidades de las comunas que autorizan esta modalidad y el Servicio del Registro Civil, propone
entonces un Sistema de Deteccin de Infractores en Autopistas Concesionadas (SisDIAC).

68

2 Sistema a ser modelado


Cada prtico de una autopista posee un armario de va, donde se almacena localmente los registros de cruce de vehculos detectados por los sensores. Peridicamente 41, desde cada armario de va se
enva una lista con los registros al data center de VaLibre. Esta lista contiene todos los cruces ocurridos desde el ltimo envo con la identificacin del prtico, hora 42 del ltimo envo, hora de cierre de la
lista, la identificacin de los vehculos (incluida una fotografa) y las horas de cruce.
Estas listas sirven tanto para que la central de VaLibre realice los clculos para la facturacin,
como para que SisDIAC detecte los infractores, de acuerdo al procedimiento indicado anteriormente y
prepare un reporte diario con la identificacin del vehculo, el registro fotogrfico con el tiempo correspondiente de cruce en cada prtico y la velocidad promedio calculada que implica la infraccin.
Este reporte est destinado a los Departamentos del Trnsito (DT) de las municipalidades correspondientes, quienes emiten finalmente partes empadronados a los propietarios de los vehculos. Para esto,
SisDIAC emite este reporte diario a la medianoche, con todos los vehculos infractores del da, accediendo a la informacin del Registro de Vehculos Empadronados del Registro Civil e Identificacin, y
agregando a la lista de vehculos, el propietario y su domicilio correspondientes.
Como es posible que exista un margen de error en clculo de las velocidades, SisDIAC utiliza el
parmetro denominado porcentaje de error permitido, cuyo valor es definido por un usuario autorizado.
Si el valor de este parmetro es 5% por ejemplo, entonces se considera infraccin en una autopista con
80 km/h como velocidad mxima, cuando la velocidad calculada supera los 84,0 km/h. Lo usual es que
este error se fije en 10%.
SisDIAC debe tener en consideracin de que si un vehculo cruza varios prticos con exceso de
velocidad, debe agruparse sus infracciones de acuerdo a los prticos que quedan bajo la jurisdiccin de
una comuna. En algunos casos es posible que un mismo vehculo reciba infraccin de parte de ms de
una municipalidad, si su desplazamiento es suficientemente extenso como para traspasar los lmites
intercomunales. Queda a criterio de cada DT, si se considera como una o varias infracciones, la deteccin de exceso de velocidad en varios prticos correspondientes a una comuna.
Adicionalmente, los Juzgados de Polica Local pueden solicitar un reporte completo para un
determinado vehculo, de manera de contrastar con la informacin de defensa de algn supuesto infractor. Este reporte detallado que emite SisDIAC, entrega todas las rutas, con horarios y fotografas de
cruce de todos los prticos, con indicacin de las infracciones de velocidad donde corresponda, para un
determinado vehculo en las fechas que se le indiquen.
Finalmente, se ha considerado que SisDIAC pueda generar algunas estadsticas tiles para campaas de divulgacin, en los diversos medios, sobre las infracciones detectadas. Inicialmente se ha considerado que el SisDIAC pueda entregar:
Las N mayores velocidades detectadas (sin identificacin de los vehculos).
Los N vehculos (sin identificacin) con mayor cantidad de infracciones en un periodo dado,
como ranking general por autopista y por municipalidad.
La cantidad de infracciones por municipalidad por da, dentro de un periodo dado, para conocer
el comportamiento en das hbiles, fines de semana y feriados.
41

Esto puede ser configurado para ser enviado a intervalo fijo (cada 5 min., por ejemplo) o por volumen fijo (cada 500
registros). Esto lo define externamente el Departamento de Operaciones para cada armario y da.
42
Las horas se expresan hasta el segundo.

69

46) Problema del Sistema de Gestin de Hardware y Software para modelamiento en grupo:
1 Antecedentes
La Escuela de Ingeniera Industrial ha definido una unidad funcional denominada Consejo de
Tecnologas de la Informacin (CTI), que se hace cargo de la planificacin y gestin de los recursos de
tecnologa de la informacin que la Escuela requiere para su funcionamiento. El presidente del CTI se
preocupa por asegurar que las decisiones estratgicas que defina este Consejo se implementen efectivamente. En el nivel ms operativo se ha definido un Administrador de Recursos TI (ARTI) que tiene
entre sus funciones:
la administracin de hardware y software, de la red, de insumos, de servicios y de los sitios web
de la Escuela
el mantenimiento correctivo y preventivo del hardware
la contratacin de servicios especializados externos e internos a la Universidad de acuerdo al
plan de servicios
la supervisin de ayudantes de laboratorio
la atencin de usuarios
la proposicin de proyectos de desarrollo al CTI
el almacenamiento de documentos y generacin de reportes al CTI
De esta manera era posible gestionar centralizada y racionalmente la adquisicin de hardware y
software necesario, sin embargo producto del crecimiento de la Escuela de Ingeniera Industrial, hoy se
realizan muchos proyectos de investigacin, innovacin y asistencia tcnica que demandan equipamiento, aplicaciones especficas y personas que los utilicen. Generalmente estos proyectos cuentan con
algn presupuesto para adquirir en forma independiente estos recursos. Esto ha llevado a que se realicen adquisiciones de equipamiento muchas veces fuera de los estndares definidos o que realmente no
son estrictamente necesarios, adems es difcil gestionar las garantas y los servicios tcnicos para este
equipamiento.
Esta situacin ha llevado a la necesidad de plantear un sistema, denominado SIGEHS (SIstema
de GEstin de Hardware y Software) que permita llevar el registro de todas las adquisiciones de hardware, gestionar los insumos (tner de impresoras, kits de mantenimiento, etc.) y mantener registro de
los software instalados, de tal manera que el ARTI pueda utilizar el sistema va web cada vez que intervenga en algn equipo, o cuando se adquiera o d de baja, o se asigne un insumo a un determinado
equipo, por citar algunos ejemplos.
2 Sistema a ser modelado
Cuando se adquiere un equipo, por ejemplo un PC de escritorio con impresora, el ARTI deber
registrar en SIGEHS la compra (datos de la factura), con el detalle de todos los componentes internos
(placa madre, disco duro, lector de DVD, etc.) y externos (monitor, teclado, mouse, parlantes, etc.), as
como el detalle de la impresora y el tipo y modelo de insumo (tinta o tner). Una vez instale el sistema
operativo y las aplicaciones especficas, deber registrarlo tambin, as como la ubicacin que tendr el
equipo y el software, y el usuario responsable (y el proyecto en que trabaje, si corresponde). Los PC
son denominados con un nombre identificador (nombres de rboles nativos chilenos: boldo, maqui,
notro, litre, ulmo, etc.) y la direccin IP (Internet Protocol) asignada para que opere en red y se conecte
a Internet. As se identifican para respaldarlos automticamente en el servidor de la Escuela. Reciente70

mente las impresoras simples y las multifuncionales tambin se les asigna un nombre (normalmente
marca+modelo+N correlativo, por ejemplo HP Colorjet 3600 n3) y tambin una direccin IP.
Los servidores (de pginas web, de impresin, de respaldo, etc.) tienen un procedimiento parecido, salvo que el usuario es el propio ARTI. Las contraseas de administracin tambin deben registrarse.
Cada vez que se actualice un componente en un equipo por parte del ARTI (por ejemplo, un
disco duro de mayor capacidad o ms memoria RAM), ste debe reflejarse en el sistema, as como los
cambios de ubicacin (por ejemplo, cambio de un PC de la oficina de un profesor a una sala de clases).
SIGEHS tambin debe llevar registro de los componentes disponibles para utilizar o dar de baja. Por
ejemplo, es usual que se tenga en stock fuentes de poder, teclados o discos duros, entre otros, para reposicin inmediata, pero tambin monitores o impresoras antiguas (antes de darse de baja), que sirven
de reemplazo frente a fallas o durante periodos de servicio tcnico.
La reposicin de insumos tambin se registra. Por ejemplo, cuando se cambie el tner amarillo
de una impresora lser color. Claramente el sistema tambin debe llevar el stock de los insumos en uso
y disponibles. Lo mismo para los kits de mantenimiento o cambios mayores (por ejemplo fusores).
Asimismo, debe registrarse si algn equipo tiene falla y debe ser llevado a servicio tcnico. La factura
de la reparacin tambin debe ingresarse al sistema, con el detalle del cambio de repuesto (por ejemplo:
cambio de unidad ptica en un escner), si corresponde.
Aparte de los equipos tradicionales, tambin SIGEHS debe mantener la informacin de los proyectores (fijos como el de esta misma sala, o mviles que se usan en charlas a colegios), sistemas de
audio (amplificador y parlantes instalados en algunas salas como la IBC 6-2), escneres y otros tipos de
equipos que todava no se conocen. Esto lleva a que el ARTI pueda definir nuevas categoras de equipos que pueden o no tener nombre, IP, responsable, insumos, ser mviles o fijos, ser respaldados o no,
etc.
Un caso especial es la categora de notebooks (netbooks, ultrabooks, tablets, etc.), ya que dependiendo del uso que se les vaya a dar, pueden tener IP definida o simplemente tener slo conexin
inalmbrica. Adems tienen asignacin temporal de usuarios, ya que, por ejemplo, un egresado puede
usarlo para trabajar en un proyecto de investigacin, y cuatro meses ms tarde, se asigna para que un
alumno de ltimo ao trabaje en un proyecto de asistencia tcnica. Adems, se debe llevar el registro
del cambio de bateras que es comn en estos equipos. Incluso, para algunos modelos ms numerosos,
se tiene un pequeo stock (1 2 bateras) para un rpido recambio.
Cierto tiempo despus que se ha comprado un equipo y la factura se ha enviado a la Direccin
de Finanzas para pago, la Unidad de Control de Gestin de dicha Direccin hace llegar una lista con las
adquisiciones recientes que corresponda asignarles un cdigo CIB (Cdigo de Inventario de Bienes) de
la PUCV y los adhesivos correspondientes con el cdigo de barra (figura al lado). El ARTI debe ubicar
los equipos y adherirles este cdigo, registrndolo en SIGEHS. Este cdigo es importante para el proceso final de baja de un equipo. Por ejemplo, si concluy la vida til de un notebook, se debe informar
la baja a la Direccin de Finanzas, indicando el cdigo CIB, con esto Contralora enva a un funcionario a verificar que el equipo es el que corresponde al cdigo, segn la factura, y con este visto bueno, el
ARTI puede registrar la baja definitiva del equipo.

71

Finalmente, el sistema debe permitir al ARTI y al CTI, consultar el historial de actualizaciones


que ha tenido un equipo: sus componentes, reparaciones, responsables, etc. A los equipos que requieran
insumos, se les debe poder consultar su historial completo. As como los equipos o componentes con
ms uso de garantas y servicios tcnicos y el stock de componentes e insumos.

47) Problema de Supportis Sistema de Apoyo al Soporte Informtico para modelamiento en grupo:
1 Antecedentes
La universidad en que trabajamos y estudiamos ha crecido de forma importante en los ltimos
aos, lo cual ha llevado a una diversificacin de las actividades desarrolladas, as como un aumento de
las personas que demandan soporte para el uso de sistemas, servicios y equipamiento informtico, en
general.
La unidad responsable de entregar este soporte se denomina Direccin de Tecnologas de la
Informacin y Comunicaciones (DTIC) y, en funcin de este crecimiento, ha decidido desarrollar el
sistema Supportis, para apoyar en el proceso de seguimiento de las llamadas al call center de atencin
informtica, por parte de los usuarios de la universidad (acadmicos, autoridades y administrativos en
general). La funcin responsable es la Unidad de Soporte de la DTIC.
El propsito de este sistema es mantener la informacin necesaria para hacer un seguimiento a
todos las denominadas incidencias, es decir, su registro, su resolucin y su cierre. Una incidencia de
soporte es un problema especfico y concreto planteado por un usuario, que puede resolverse relacionando su origen con una sola causa en el mbito de la informtica.
2 Sistema a ser modelado
Supngase un usuario que tiene una falla en su PC de escritorio. Este usuario no puede (o no
quiere) resolver el problema por si mismo y decide llamar al call center de la Unidad de Soporte de la
DTIC. El tcnico que recibe la llamada queda automticamente asignado a la incidencia y registra los
siguientes datos: identificacin del usuario, contacto preferido (anexo o correo electrnico), fecha de
ocurrencia, hora de ocurrencia y descripcin. Las incidencias las clasifica el tcnico asignado (denominado tcnico principal) de acuerdo a las siguientes categoras: sistema operativo, aplicacin local, aplicacin especializada (software de uso de ciertas unidades de la universidad), sistema institucional, servicio de conectividad, hardware y no clasificado (con indicacin de un comentario). En esta instancia el
tcnico adems define el estado de la incidencia (en resolucin), prioridad (urgente o normal),
causa de la solucin (pendiente) y se omite la fecha y hora de la solucin. A partir de ese momento,
este tcnico tiene la responsabilidad de trabajar para resolver el problema del usuario, puede consultar
su estado y puede actualizarlo, conjuntamente con la causa, fecha y hora de la solucin.
Los usuarios estn registrados en Supportis, consignando su nombre, apellido, ubicacin en la
universidad y PC asignado. Asimismo, todos los tcnicos tambin lo estn en trminos de su RUN,
nombre y apellido. La actualizacin de estos datos se realiza todos los semestres en forma centralizada
por la DTIC.

72

Una vez que la incidencia est en resolucin, el tcnico puede intentar resolverla telefnicamente en el mismo momento del contacto inicial o posteriormente (si requiere consultar informacin tcnica, por ejemplo), o por medio de una visita coordinada con el usuario, si el caso lo amerita. Si logra la
resolucin telefnica, el tcnico principal registra los datos correspondientes a la solucin, junto con el
cierre formal de la incidencia.
Si se requiere una visita, sta puede hacerla el mismo tcnico principal, si no es urgente. Si es
urgente, Supportis asigna automticamente, segn las asignaciones previas, un tcnico visitador de un
conjunto disponible para estos efectos, para que concurra a lo ms, medio da hbil despus de recibida
la llamada. En este caso, el estado de la incidencia pasa de en resolucin a visita urgente y se indica el tcnico visitador, junto con la fecha y hora de la visita. Si no es urgente, el tcnico principal tiene
hasta 2 das hbiles para resolver, indicando el estado visita programada a la incidencia. Una vez
resuelto el problema del usuario por el tcnico principal o visitador, el tcnico visitador genera un breve informe al tcnico principal, para que ste pueda completar los datos de la solucin y cierre de la
incidencia.
Supportis tiene integrado los niveles de servicio para la visitas urgentes y programadas. Si alguna incidencia no tiene su estado modificado a cierre en los plazos respectivos, emite un alerta al Supervisor de Soporte. As al ingresar al sistema, el Supervisor puede ver qu incidencias an estn sin resolver, tanto dentro como fuera de los plazos, e indagar, para estas ltimas, las causas de los atrasos con
los tcnicos principales y/o visitadores.
Para fines de evaluacin del servicio entregado por la Unidad de Soporte de la DTIC y en particular su unidad de soporte, quincenalmente Supportis selecciona en forma aleatoria, un 20% de las incidencias del periodo, para que el Supervisor contacte a los usuarios y les consulte respecto de la calidad de la solucin a sus problemas. El Supervisor registra las respuestas de los usuarios en una escala
de 1 a 5 (1 muy insatisfecho, 2 insatisfecho, 3 indiferente, 4 - satisfecho y 5 muy satisfecho),
respecto de la rapidez de la solucin, de la efectividad de la misma y de la atencin brindada por el
tcnico principal y por el tcnico visitador, si corresponde.
Finalmente, el Supervisor tambin puede consultar los siguientes reportes a Supportis (todos se
asumen para el mes recin vencido cuando solicitados, salvo se indique un periodo determinado):
distribucin en el tiempo de las incidencias totales atendidas por la DTIC en el periodo;
cantidad y porcentaje de incidencia atendidas por tcnicos principales y visitadores para el periodo;
clasificacin de incidencias por tipo para el periodo; y
promedio de la satisfaccin de los usuarios en general, por tcnico principal y visitador para el
periodo determinado.

48) Problema del Sistema Canal Digital DigiVal para modelamiento en grupo:
1 Antecedentes
La empresa Comunicaciones Digitales Valparaso Ltda. ha obtenido la concesin para emisiones de televisin digital en seal abierta, creando el canal DigiVal que iniciar sus transmisiones en
2015.
73

Siendo una seal abierta, no tiene costo para el pblico en general, pero como parte del modelo
de negocio, se desea ofrecer servicios denominados premium, que haciendo uso de la tecnologa interactiva de la televisin digital, permitan ofrecer al cliente servicios de mayor valor por los cuales est
dispuesto a pagar.
Frente a este desafo, se requiere disear un sistema informtico para apoyar las operaciones de
este nuevo canal. El canal se pretende sea pequeo, pero orientado a las necesidades de los clientes de
la comunidad local, explotando las caractersticas de la televisin digital abierta.
2 Sistema a ser modelado
Los roles de la empresa, que inicialmente sern apoyados por este sistema, son los siguientes:
Jefe de Programacin: Es el responsable de la elaboracin de la parrilla de programacin de DigiVal.
Cuando requiera definir o modificar la parrilla del canal, deber hacerlo en el sistema.
Jefe de Suscripcin: Se preocupa de gestionar las suscripciones a servicios premium que se
ofrecern por medio del canal digital, tales como retransmisiones deportivas, conciertos, pelculas de estreno, etc. Tambin es de su responsabilidad responder a los reclamos que puedan
hacer llegar los suscriptores.
Gerente General: Se prev que el sistema provea al Gerente General de informacin relativa a la
programacin del canal, entregando los programas clasificados por criterio y tipo, y los suscriptores y reclamos categorizados por periodo indicado.
Suscriptores: Los suscriptores, por medio de la interfaz interactiva habilitada por la seal digital
en los televisores certificados, pueden comprar y visualizar los programas contratados, navegando por los diferentes mens en su televisor digital e interactuar mediante teclados virtuales 43.
En general, los programas se clasifican de acuerdo a dos principales criterios: 1) el carcter
estndar o premium del programa; y 2) el tipo de tema del programa (serie, pelcula, concierto, documental, etc.). Sin embargo, se tiene conciencia que a futuro se van a generar otros tipos dentro de los
criterios actuales 44 o definir nuevos criterios 45. Dentro del plan estratgico est contemplada la produccin de programas propios orientados a la comunidad local, que exploten la interactividad del medio,
en un plazo no superior a dos aos. Esto abre ms tipos y categoras posibles, no definibles an.
Respecto de las tareas especficas que el sistema debe apoyar, se pueden mencionar las siguientes: determinacin de programas, gestin de suscriptores, compra y visualizacin de emisiones y recepcin de reclamos.
En el caso de la determinacin de programas, el Jefe de Programacin puede realizar diferentes
operaciones: dar de alta, dar de baja o modificar programas. Para el alta de un nuevo programa, el Jefe
de Programacin deber identificar el programa, el precio de retransmisin para los suscriptores, los
tipos dentro de las categoras existentes y el vnculo al contenido del programa. El sistema confirmar
la inclusin del programa a la planilla entregando un progId que lo identifica nicamente en la progra43

Tambin es posible utilizar teclados fsicos inalmbricos, dependiendo del estndar que utilice el fabricante del televisor.

44

Por ejemplo, se espera diversificar los servicios premium en categoras lite, home y pro, cuando se evale el desempeo del canal, al cumplir el primer ao de

transmisiones.
45

Tal como el pblico objetivo, por ejemplo: todo espectador, adolescente y adulto.

74

macin. Caso exista algn tipo de error, deber tambin indicarlo. Para modificar un programa, se debe
indicar explcitamente el progId y cambiar su fecha y hora de emisin, por ejemplo. La baja de los programas es similar a la modificacin, slo que el sistema debe pedir adems confirmacin y el ingreso
de la contrasea del Jefe de Programacin, para asegurar que la eliminacin es correcta o para informar
que la eliminacin est imposibilitada 46.
La gestin de los suscriptores incluye, anlogamente a la de los programas, las posibilidades de
alta, modificacin y baja de los mismos. Cuando el Jefe de Suscripcin desee dar de alta a un suscriptor, debe ingresar sus datos personales tales como RUT, nombre y apellidos, direccin, telfono de contacto, correo electrnico, medio de pago, etc. Es posible modificar todos los datos de un suscriptor excepto el RUT. Para dar de baja un suscriptor, se debe identificarlo con el RUT.
La suscripcin a los servicios premium permite al cliente cualquiera, comprar emisiones no disponibles en el tiempo o en el espacio de la seal abierta. Por ejemplo, puede tener acceso a un partido
de ftbol que se transmiti anteriormente o a un concierto exclusivo para los suscriptores, respectivamente. Para estos efectos, los suscriptores acceden al men interactivo de su televisor digital, donde
podrn navegar revisando los programas disponibles y su precio respectivo 47. Cuando el suscriptor o el
cliente en general (para los programas gratuitos) desee comprar, debe seleccionar el o los programas e
indicar que desea comprarlos. A cambio, el sistema le solicitar su identificacin y contrasea de suscriptor, que autoriza el cargo al medio de pago registrado, si corresponde. Una vez confirmada la compra, el sistema agrega el o los programas a la carpeta del suscriptor 48, desde la cual puede seleccionar y
visualizar libremente, las veces que quiera, el programa mientras contine siendo suscriptor 49.
El suscriptor tambin puede emitir reclamos, consultas o sugerencias y revisar sus respuestas,
por medio de la mensajera disponible tambin en la plataforma de su televisor digital, previa identificacin tanto para colocar mensajes, como para acceder posteriormente a las respuestas.

46

No se puede eliminar programas que ya estn vinculados en carpetas de suscriptores (ver siguientes notas al pie).

47

Algunos programas estarn disponibles gratuitamente por periodos limitados, para servir de enganche para contratar servicios para quien an no es suscriptor.

48

La carpeta contiene realmente slo vnculos a los programas, por lo que no se requiere mucho espacio de almacenamiento para los suscriptores. Estos pro-

gramas pueden ser visualizados desde cualquier televisor digital del rea de la seal abierta, siempre y cuando el suscriptor se identifique.
49

Las compras de programas gratuitos en promocin, cuando realizadas por un cliente cualquiera, se almacenan en una carpeta del dispositivo, asociada al

televisor desde el cual fueron seleccionados, por medio de su identificador de hardware, y slo estn disponibles por 7 das corridos desde la fecha en que fueron comprados.

75

Soluciones a Ejercicios de Integracin de Modelos


4) DCla de un DPC:
Flujo de Control

Componente

1..* Comunicacin 1..1

nombre
sentido

nombre
{Un objeto de Controlador no
puede asociarse consigo mismo
por medio de Flujo de Control }

1..*

{completo,disjunto}

Comunicacin

Controlador

Controlado

Terminador

1..1

5) a) DME
disponible
clienteReservaSemana(pago)
[pago=0]

confirmadoNoReservado

clienteReservaSemana(pago)
[pago>0]

reservadoConfirmado

clienteReservaSemana(pago)
[pago>0]

6) a) DTE del proceso de control

en reposo
Clave no vlida

Emite "Clave
incorrecta"

Se recibe llamada

Emite "Ingrese clave vendedor"


Validar clave vendedor
esperando
clave

Cdigo Artculo no vlido

Emite "Cdigo incorrecto"


Validar cdigo artculo

Clave vlida

Emite "Ingrese cdigo artculo"


Validar cdigo artculo

Cdigo artculo nulo

Emite "Gracias
por la consulta"

esperando
cdigo

Cantidad Reserva nula

Emite "No existe reserva"


Validar cdigo artculo

Cdigo Artculo vlido

Consultar stock artculo


Emite "Artculo con stock", stock artculo
Emite Ingrese cantidad a reservar
Validar cantidad reserva
esperando
cantidad
Cantidad reserva vlida

Emite Artculo reserva, cantidad reserva


Reservar cantidad reserva de artculo para vendedor
Disminuir mnimo(cantidad reserva, stock artculo) de stock artculo
Validar cdigo artculo

76

b) DFD no jerarquizado
Reservas por vendedor

VENDEDORES

clave

Reservar
artculo

cdigo para reserva

clave vendedor

Validar
clave
vendedor
STOCKS
Validar
cdigo
artculo

cantidad-en-stock

clave
VENDEDORES

Consultar
stock

cdigo artculo vlido


cdigo
ARTICULOS

stock artculo
cantidad

cdigo artculo

clave vendedor vlida

c) DPC
Se recibe llamada
clave vlida

Reservar
artculo

cantidad vlida

Control
consulta y
reserva

clave no vlida

cdigo vlido
cdigo no vlido
cdigo nulo

Validar
clave
vendedor

cantidad nula
Validar
cdigo
artculo
Consultar
stock

7) Las estrategias de modelamiento enmarcadas en el paradigma de proceso son las del Anlisis Estructurado Moderno y Enfoque STATEMATE.
I. Anlisis Estructurado Moderno (AEM)
Supuesto: Se asume que existe una secuencia en la elaboracin del proyecto.

77

Modelo Esttico: DER


CONTRATISTA

PROYECTO

CONTRATISTA (1, n)
EN OBRAS

(1, n)

realiza

PROYECTO
EN
EJECUCION

Modelo Funcional: DFD de contexto


Oficina
Nacional
de Riego

propuesta adjudicada

proyecto definitivo financiado

Contratista
adjudicado

informe de avance

Agricultor
solicitud

Sistema
Oficina
Regional
de Riego

antecedentes
informe inspeccin ocular

orden de materiales
llamado propuesta
datos contratista

Contratista
datos tcnicos

Tcnico

propuestas
proyecto auspicioso
factibilidad inicial

DIRECCION
OF.REGIONAL
DE RIEGO

anteproyecto

Diagrama 0
SOLICITUD

1.

FACTIBILIDAD INICIAL

ELABORAR
FACTIBILIDAD
INICIAL
INFORME INSPECCION
OCULAR

PROYECTO AUSPICIOSO
DATOS CONTRATISTA
PROYECTO DEFINITIVO FINANCIADO
ANTECEDENTES

2.
ELABORAR
ANTE
PROYECTO

LLAMADO PROPUESTA
ANTEPROYECTO

4.
ACTUALIZAR
CONTRATISTAS

3.

DATOS TECNICOS

ELABORAR
BASES
TECNICAS
CONTRATISTAS
PROPUESTAS

PROYECTOS

5.
ADJUDICAR
PROPUESTA
PROYECTO EN
EJECUCION
realizan
PROPUESTA ADJUDICADA
AVANCE PROYECTO

ORDEN DE PAGO

7.
PROVEER
RECURSOS
PROYECTO

78

INFORME DE AVANCE

6.
CONTROLAR
AVANCE
PROYECTO

CONTRATISTAS
EN OBRA

Modelo Dinmico:
DPC

CONTROL
PROYECTOS

FACTIBILIDAD OK

1.
ELABORAR
FACTIBILIDAD
INICIAL
CONTROL
CONTRATISTAS

ANTEPROYECTO OK

ADJUDICACION
PROPUESTA OK

BASES TECNICAS OK
CONTRATISTA OK

2.
ELABORAR
ANTE
PROYECTO

3.

4.
ACTUALIZAR
CONTRATISTAS

ELABORAR
BASES
TECNICAS

5.
ADJUDICAR
PROPUESTA

6.
CONTROLAR
AVANCE
PROYECTO

7.
PROVEER
RECURSOS
PROYECTO

PROVISION OK

CONTROL
RECURSOS

AVANCE OK

DTE del proceso de control CONTROL RECURSOS

esperando
avance
avance OK

Proveer recursos proyecto

provisin OK

esperando
provisin

79

DTE del proceso de control CONTROL PROYECTOS

Elaborar Factibilidad inicial

Esperando
Factibilidad
Inicial
Factibilidad OK

Elaborar Anteproyecto

Esperando
Anteproyecto
Anteproyecto OK

Elaborar Bases Tcnicas

Avance OK

Elaborar Factibilidad inicial


Bases Tcnicas OK

Adjudicar Propuesta

Esperando
Propuesta
Adjudicada

Adjudicacin Propuesta OK

Controlar Avance Proyecto

Esperando
Bases Tcnicas

Esperando
Avance

DTE del proceso de control CONTROL CONTRATISTAS

Actualizar contratista

esperando
contratista

contratista OK

Actualizar contratista

II. Enfoque STATEMATE (ES)


Supuesto: Se asume que existe una secuencia en la elaboracin del proyecto. Esto lo hace comprable
directamente con los modelos del AEM.
Modelo Esttico: El mismo diagrama del AEM
Modelo Funcional:
DFD de contexto y 0: Los mismos diagramas del AEM.

80

Modelo Dinmico: DPC

PROVISION OK

CONTROL
PROYECTOS
FACTIBILIDAD OK

1.
ELABORAR
FACTIBILIDAD
INICIAL
ADJUDICACION
PROPUESTA OK

CONTRATISTA OK
ANTEPROYECTO OK

BASES TECNICAS OK

2.
ELABORAR
ANTE
PROYECTO

4.
ACTUALIZAR
CONTRATISTAS

3.
ELABORAR
BASES
TECNICAS

5.
ADJUDICAR
PROPUESTA

7.
PROVEER
RECURSOS
PROYECTO

6.
CONTROLAR
AVANCE
PROYECTO

AVANCE OK

81

SCH
Oficina Regional de Riego
Elaboracin Proyectos

/ activar ( Elaborar
Factibilidad inicial )

Avance OK / activar( Elaborar Factibilidad


inicial )
Esperando
Esperando
Factibilidad
Avance
Inicial

Factibilidad OK / activar(
Elaborar Anteproyecto )

Bases Tcnicas OK /
activar( Adjudicar
Propuesta )

Esperando
Anteproyecto
Anteproyecto OK / activar(
Elaborar Bases Tcnicas )

Adjudicacin Propuesta OK /
activar( Controlar Avance
Proyecto )
Esperando
Propuesta
Adjudicada

Esperando
Bases Tcnicas

Actualizacin Contratistas

/ activar( Actualizar
Contratista )
Esperando
Contratista

Contratista OK / activar(
Actualizar Contratista )

Entrega Recursos

Esperando
Avance

Provisin OK

Esperando
Provisin

Avance OK / activar( Proveer


Recursos Proyecto )

82

11) a) La clase ms compleja, de acuerdo al DCom dado, es Comando, ya que presenta la mayor cantidad de mensajes de interaccin (7 en total). El DME correspondiente a esta clase es:

mostrandoHorasMinutos
entry / mostrarHorasMinutos
selectPresionado / ajustarHoras

ajustandoHoras
setPresionado /
incrementarHoras
selectPresionado / ajustarMinutos

ajustandoMinutos
setPresionado /
incrementarMinutos

selectPresionado

12) DCU (con actores principales y secundarios):


Sistema Biblioteca

Hacer reserva
incluye

Cancelar
reserva
incluye
incluye

Identificar
ttulo y usuario

Prestar
ejemplar

Usuario

Empleado
Biblioteca

incluye

Devolver
ejemplar
Administrar
biblioteca
Empleado
Biblioteca

Agregar
usuario
Agregar
ttulo

Modificar ttulo

Agregar
ejemplar

Eliminar
ejemplar

Modificar usuario

83

DCla:
Ttulo
Ejemplar
Copia

nmero

1 nombre
autor
isbn
/nmeroReservas

eliminaPorTtulo()
crea()
elimina()
prestaEjemplar()
devuelveEjemplar()

ObjetoReserva

busca()
crea()
identificaTtuloUsuario()
modificaTtulo()
agregaEjemplar()
eliminaEjemplar()
liberaReserva()
reserva()
incrementaNmeroReservas()
decrementaNmeroReservas()

{disjunto, completo}

EjemplarParaPrstamo
0..1

Revista

Libro
Prstamo
periodoPrstamo: Das=30

periodoPrstamo: Das=10

fecha: fecha=fechaActual
crea()
elimina()
busca()
Usuario

*
ReceptorPrstamo

Reserva

rut
nombre
1 direccin
busca()
crea()
elimina()
modificaUsuario()

AutorReserva
1

fecha: fecha=fechaActual
*
busca()
crea()
elimina()
creaReserva()
eliminaReserva()

DCom:
a) CU: Identificar ttulo y usuario
identificaTtuloUsuario()

1: busca()
u: Usuario

t: Ttulo

Empleado
Biblioteca

b) CU: Hacer reserva incluye Identificar ttulo y usuario


creaReserva()

1: identificaTtuloUsuario()
r: Reserva

Empleado
Biblioteca

1.1: busca()
t: Ttulo

u: Usuario

2: reserva()

84

c) CU: Cancelar reserva incluye Identificar ttulo y usuario


eliminaReserva()

1: identificaTtuloUsuario()

1.1: busca()
t: Ttulo

r: Reserva

u: Usuario

2: liberaReserva()

Empleado
Biblioteca

d) CU: Prestar ejemplar incluye Identificar ttulo y usuario


prestaEjemplar()

1: identificaTtuloUsuario()

1.1: busca()
t: Ttulo

e: Ejemplar

u: Usuario

5a: liberaReserva()

Empleado
Biblioteca

2: crea()
p: Prstamo
3: busca()
r: Reserva
4a: elimina()

e) CU: Devolver ejemplar incluye Identificar ttulo y usuario


devuelveEjemplar()

1: identificaTtuloUsuario()
e: Ejemplar

Empleado
Biblioteca

1.1: busca()
t: Ttulo

u: Usuario

2: busca()
p: Prstamo
3: elimina()

f) CU: Agregar ttulo


1: crea()
t: Ttulo

Empleado
Biblioteca

g) CU: Modificar ttulo


1a*:eliminaPorTtulo()

modificaTtulo()
t: Ttulo

: Ejemplar

Empleado
Biblioteca

85

h) CU: Agregar ejemplar


agregaEjemplar()

1: crea()
t: Ttulo

e: Ejemplar

Empleado
Biblioteca

i) CU: Modificar usuario


modificaUsuario()
u: Usuario

Empleado
Biblioteca

j) CU: Eliminar ejemplar


eliminaEjemplar()

1: elimina()
e: Ejemplar

t: Ttulo

Empleado
Biblioteca

k) CU: Agregar usuario


1: crea()
: Usuario

Empleado
Biblioteca

DME Clase Ttulo (clase con ms interacciones segn los DCom):


estadoTtulo
identificaTtuloUsuario() / busca()
agregaEjemplar() / crea()
eliminaEjemplar() / elimina()

[opcinElimina] /
*eliminaPorTtulo()
modificaTtulo()

disponible
entry / nmeroReservas=0

[opcinActualiza]
[nmeroReservas=1]
reserva() /
incrementaNmeroReservas()

C
liberaReserva()

[nmeroReservas>1] /
decrementaNmeroReservas()

reservado
reserva() / incrementaNmeroReservas()

86

17) Modelo Esttico


DER:
DISPOSITIVO
(t, e)

es hecha
en

(1, 1)

LINEA DE
LLAMADA

LINEA B

(0, n)

LINEA SALIDA

RUTA

CONMUTADOR

(0, n)
LINEA A

(1, n)

LLAMADA
(1, n)

tiene2

est
compuesta
de

(0, n)
(1, 1)
posee
(1, 1)

(0, n)
tiene1

(0, 1)

se aplica
(0, 1)
(0, n)
SUSCRIPTOR
TARIFA
(0, n)
est
conectado
a

(1, 1)

DD (slo para DER):


conmutador
dispositivo
est compuesta de
est conectado a
lnea A
lnea B
lnea llamada
lnea salida
llamada
posee
ruta
se aplica
suscriptor
tarifa
tiene1
tiene2

= *subentidad de dispositivo *
= @identidad dispositivo + nombre + ubicacin
= * relacionamiento entre lnea salida y ruta *
= * relacionamiento entre suscriptor y conmutador *
= *subentidad de lnea llamada *
= *subentidad de dispositivo *
= *subentidad de dispositivo *
= *subentidad de dispositivo *
= @identificador llamada + fecha + hora + duracin + tiempo espera + n llamado
= * relacionamiento entre conmutador y ruta *
= *subentidad de dispositivo *
= * relacionamiento entre llamada y tarifa *
= @identidad suscriptor + nmero + categora
= @hora + valor
= * relacionamiento entre lnea A y suscriptor *
= * relacionamiento entre lnea B y suscriptor *

87

23) Modelo Esttico


DER:
se
clasifica1

(1, n)

TIPO
SERVICIO

(1, n)

(0, n)

se
clasifica2

(0, n)
(0, n)

(1, n)

se ofrece
en

AREA
GEOGRFICA

(1, n)

se
demanda
en

(0, n)

DEMANDA

PERSONA

DEMANDANTE

demanda

(1, n)

OPORTUNIDAD

(t, e)

(t, s)

ORGANIZADOR
VOLUNTARIO

(0, n)

PERSONA
DEMANDANTE

VOLUNTARIO

ORGANIZACION
LOCAL
VOLUNTARIA

(1, n)

(0, n)
acepta

ofrece

(0, n)

ACUERDO

(0, n)

(1, 1)

se somete
a

(1, n)

HABILIDAD

(1, n)

tiene
(1, 1)

MOVIMIENTO
DE TIEMPO

OFERTA
(1, 1)
{ DEMANDA que gira CARGO DE TIEMPO es un subconjunto de DEMANDA que se
somete a ACUERDO de la OFERTA que tiene MOVIMIENTO DE TIEMPO }

CARGO DE
TIEMPO

(1, 1)

gira

26) Convenciones, observaciones y supuestos del problema

Convencin de notacin para las Especificaciones de Proceso:


Elemento
elementos del DD (a excepcin de los depsitos)
DEPSITOS
instrucciones (PARA, SI, CASO, etc.)
acciones (INCREMENTAR, ACCESAR, EMITIR, etc.)
variables locales de los procesos

negrita

minscula

MAYSCULAS

Cliente posee instancias de clientes registrados y clientes annimos. Clientes annimos son aquellos que han pasado a caja o no se han registrado hasta el momento. Adems se entiende por clientes annimos a aquellos cuyos pedidos han sido despachados, por lo que se mantiene una instancia
en Cliente que los representa para que la empresa pueda saber cules pedidos ya fueron despachados.

88

La primera cesta de cada cliente es siempre no identificada. Por lo tanto, si el cliente se va y no la


identifica, entonces esta cesta es eliminada.

Las personas que slo navegan por la pgina de Marraqueta, no estn individualizadas por la empresa y no se representan en el sistema.

No existe un stock mnimo para cada artculo. Si el stock en bodega es mayor que la cantidad solicitada en un pedido, entonces se reduce el stock disponible y se satisface el pedido. Si el stock es
menor que la cantidad, entonces se emite una orden a proveedor.

Se entiende actualizar en general, como agregar un elemento nuevo o modificar uno existente dentro del depsito.

Una cesta puede ser identificada en cualquier momento, mediante el proceso de Asignar nombre a
cesta.

Modelamiento Esttico: Modelo Clusterizado del DER

Categora

Empresa

{ dominancia }

Cliente

{ dominancia }

Categora

(1, n)

clasificacin

Empresa

(1, n)

{ abstraccin }

Producto

{ abstraccin }

Cliente

Flete

{ dominancia }

{ abstraccin }

89

Categora

(1, n)

clasificacin

Empresa

(1, n)
{ abstraccin }
pertenencia

(0, n)

Cesta

(0, n)

contenido

(1, n)

Producto

(1, n)

inclusin
{ abstraccin }

(0, 1)

Cliente

(0, n)
(1, 1)

(0, n)

solicitud

Pedido
(0, n)

{ abstraccin }

Flete
(1, 1)

consignacin

{ abstraccin }

90

Modelamiento Esttico: DER


Empresa
(t, e)

Categora

(1, n)

(1, n)

clasificacin

(1, 1)

provisin

Proveedor

Courier
(1, 1)

(1, n)
pertenencia

(0, n)

Cesta

(0, n)

contenido

(1, n)

Producto

(1, n)

(t, e)
inclusin
(0, 1)
(1, 1)

Cliente

Cd

Libro

Video
servicio

(0, n)
Cliente
Registrado

(0, n)

solicitud

(t, e)

(0, n)

Flete
Cliente
Eventual

Pedido

(1, 1)

Cliente
Permanente

consignacin

Flete Expreso
(1, n)

92

Modelamiento Esttico: Diccionario de Datos


autorizacin pago =
aviso pago =
cancelamiento pedido =
cancelamiento producto =
categora =
categora a actualizar =
categoras =
cd =
cd a actualizar =
cd modificado =
cd nuevo =
cds =
cesta =
cestas =
clasificacin =
cliente =
cliente a actualizar =
cliente eventual =
cliente modificado =
cliente nuevo =
cliente permanente =
cliente registrado =
clientes =
clientes eventuales =
clientes permanentes =
clientes registrados =
consignacin =
contenido =
contenidos =
courier =
courier modificado =

* autorizacin recibida para cada pedido desde finanzas; valores [ Si | No ] *


nmero pedido + monto + fecha
* se indica que el pedido ha sido cancelado porque su(s) producto(s) ha(n) excedido el plazo de entrega correspondiente *
* se indica que el producto ha sido cancelado del pedido por haber excedido el plazo de entrega correspondiente *
@cdigo categora + nombre categora
cdigo categora + nombre categora
{ categora }
* subentidad de Producto * 1{ artista } + sello + catlogo + { pista + ( duracin ) } + ( duracin total ) + formato
digital + nmero de unidades + { extracto }
[ cd modificado | cd nuevo ]
{ artista } + ( sello ) + ( catlogo ) + { pista + ( duracin ) } + ( duracin total ) + ( formato digital ) + ( nmero de
unidades ) + { extracto }
1{ artista } + sello + catlogo + { pista + ( duracin ) } + ( duracin total ) + formato digital + nmero de unidades + { extracto }
{ cd }
@id cesta + estado cesta + ( nombre cesta )
{ cesta }
* relacionamiento entre Producto y Categora *
@id cliente
[ cliente modificado | cliente nuevo ]
* subentidad de Cliente Registrado * [ direccin de despacho | direccin de regalo ]
id cliente + ( nombre cliente ) + ( correo electrnico ) + ( direccin personal ) + ( forma de pago ) + { [ direccin
de despacho | direccin de regalo ] } + ( cdigo cliente ) + ( contrasea )
nombre cliente + ( correo electrnico ) + direccin personal + forma de pago + 1{ [ direccin de despacho |
direccin de regalo ] } + cdigo cliente + contrasea
* subentidad de Cliente Registrado * 1{ [ direccin de despacho | direccin de regalo ] }
* subentidad de Cliente * nombre cliente + ( correo electrnico ) + direccin personal + forma de pago + cdigo
cliente + contrasea
{ cliente }
{ cliente eventual }
{ cliente permanente }
{ cliente registrado }
* relacionamiento entre Pedido en Proceso y Flete *
* relacionamiento entre Cesta y Producto * cantidad
{ contenido }
* subentidad de Empresa *
empresa modificada

93

courier nuevo =
couriers =
descontinuacin =
descripcin avanzada =
descripcin producto =
despacho =

detalle pedido =
disponibilidad =
empresa =
empresa modificada =
empresa nueva =
empresas =
estado cesta =
estado pedido =
estado producto =
evaluacin =
fecha de inicio =
fecha de trmino =
flete =
flete a actualizar =
flete expreso =
flete modificado =
flete nuevo =
fletes =
forma de pago =
formato digital =
foto =
identificacin cesta =
identificacin cesta a nombrar =
identificacin cesta para eliminar =
identificacin cesta pasada a caja =
identificacin pedido =
identificacin producto =
identificacin producto a cancelar =
identificacin producto cancelado =

empresa nueva
{ courier }
* se indica que el producto no est ms disponible para la compra *
lugar ranking ventas + lugar ranking preferencias + productos asociados + [ { extracto } | { sinopsis } | { trozo } ]
producto + [ cd | video | libro ]
id cliente + nombre cliente + direccin personal + [ direccin de despacho | direccin de regalo ] + nmero
pedido + tipo despacho + 1{ cdigo producto + ttulo + precio + cantidad + subtotal } + total productos + valor
tipo flete + total pago
despacho + forma de pago
* disponibilidades de entrega de los productos; valores [ 1-2 das | 7-10 das | 21-30 das | desconocida | discontinuada ] *
@RUT + razn social + direccin + 1{ fono } + { fax } + representante
RUT + ( razn social ) + ( direccin ) + { fono } + { fax } + ( representante )
RUT + razn social + direccin + 1{ fono } + { fax } + representante
{ empresa }
* define si una cesta puede (activa) o no (no activa) recibir productos; valores [ activa | no activa ] *
* define en qu estado se encuentra un pedido con base en los productos que incluye; valores [ solicitado | en
proceso | cerrado ] *
* define en qu estado se encuentra un producto en un pedido[ solicitado | en stock | en trnsito | cancelado |
despachado ]
* calificacin de un producto hecha por los clientes; valores [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 ] *
* fecha inicial para un periodo de consulta *
* fecha final para un periodo de consulta *
@id flete + tipo flete + cargo fijo + cargo variable
[ flete nuevo | flete modificado ]
* subentidad de Flete *
( courier modificado ) + id flete + ( tipo flete ) + ( cargo fijo ) + ( cargo variable )
( courier nuevo ) + id flete + tipo flete + cargo fijo + cargo variable
{ flete }
[ cheque US$ | depsito en cuenta bancaria | tarjeta de crdito ]
* tipos de grabacin, mezcla y masterizacin (A=Anlogo y D=Digital), respectivamente, indicada en los CD;
valores [ AAD | ADD | DDD ] *
* imagen de la portada del producto *
id cesta + tipo flete + tipo despacho
id cesta + nombre cesta
id cesta
id cesta
nmero pedido
cdigo producto + ( [ id cliente | id cesta ] )
identificacin producto en pedido
identificacin producto en pedido

94

identificacin producto en pedido =


identificacin producto sin stock =
inclusin =
inclusiones =
libro =
libro a actualizar =
libro modificado =
libro nuevo =
libros =
lista de despachos =
lista productos =
mensaje pedido despachado =
mensaje pedido en proceso =
mensaje pedido solicitado =
palabra =
pedido =
pedido cancelado =
pedido en proceso =
pedidos =
periodo =
pertenencia =
producto =

producto a actualizar =
producto a describir =
producto asociado =
producto cancelado =
producto comentado =
producto modificado =

nmero pedido + cdigo producto


identificacin producto en pedido
* relacionamiento entre Producto y Pedido * { estado producto + cantidad en estado } + cantidad producto
{ inclusin }
* subentidad de Producto * 1{ autor } + { editor } + editorial + ndice contenidos + ISBN + ( edicin ) + ( reimpresin ) + ( formato encuadernacin ) + ( nmero pginas ) + nmero volmenes + { trozo }
[ libro modificado | libro nuevo ]
{ autor } + { editor } + ( editorial ) + ( ndice contenidos ) + ( ISBN ) + ( edicin ) + ( reimpresin ) + ( formato
encuadernacin ) + ( nmero pginas ) + ( nmero volmenes ) + { trozo }
1{ autor } + { editor } + editorial + ndice contenidos + ISBN + ( edicin ) + ( reimpresin ) + ( formato encuadernacin ) + ( nmero pginas ) + nmero volmenes + { trozo }
{ libro }
1{ nmero pedido }
tipo producto + palabra buscada + cdigo producto + ttulo + disponibilidad + precio + ao publicacin
correo electrnico + despacho
correo electrnico + nmero pedido + estado pedido + fecha actual
correo electrnico + detalle pedido
tipo producto + palabra buscada
@nmero pedido + fecha + tipo despacho + estado pedido + autorizacin pago + fecha cierre
nmero pedido + fecha + fecha cierre + cancelamiento pedido
nmero pedido
{ pedido }
fecha de inicio + fecha de trmino
* relacionamiento entre Cesta y Cliente *
@cdigo producto + ttulo + 1{ idioma }+ observaciones + disponibilidad + stock + foto + descuento + precio +
ao publicacin + lugar publicacin + { rol + comentario + ( evaluacin ) } + posicin de venta + posicin de
preferencia + cantidad vendida + promedio evaluaciones
[ producto nuevo | producto modificado ]
cdigo producto
@cdigo producto + 1{ cdigo producto asociado + frecuencia }
nmero pedido + cdigo producto + ttulo + cancelamiento producto
rol + cdigo producto + comentario
cdigo producto + ( ttulo ) + { idioma }+ ( observaciones ) + ( disponibilidad ) + ( foto ) + ( descuento ) + ( precio ) + ( ao publicacin ) + ( lugar publicacin ) + { rol + comentario + ( evaluacin ) } + { nombre categora }

95

producto nuevo =

producto seleccionado =
productos =
productos asociados =
productos descontinuados =
proveedor =
proveedor modificado =
proveedor nuevo =
proveedores =
provisin =
provisin a actualizar =
provisin modificada =
provisin nueva =
recepcin de compra =
reposicin de stock =
rol =
servicio =
sistema =
solicitud =
solicitud de compra =
status pedido =
subttulos =
tipo despacho =
tipo flete =
tipo producto =
top 100 CDs =
top 100 libros =
top 100 preferencias =
top 100 solicitado =
top 100 ventas =
top 100 videos =
ventas por cliente =

ventas por producto =

cdigo producto + ttulo + 1{ idioma }+ observaciones + disponibilidad + foto + descuento + precio + ao publicacin + lugar publicacin + { rol + comentario + ( evaluacin ) } + 1{ nombre categora } + 1{ nombre categora
}
cdigo producto
{ producto }
* depsito de implementacin relacionado con productos * { producto asociado }
1{ cdigo producto + ttulo + descontinuacin }
* subentidad de Empresa *
empresa modificada
empresa nueva
{ proveedor }
* relacionamiento entre Producto y Proveedor *
[ provisin nueva | provisin modificada ]
proveedor modificado + { cdigo producto }
proveedor nuevo + 1{ cdigo producto }
cdigo producto + cantidad recibida + ( disponibilidad )
1{ cdigo producto + cantidad solicitada }
* define el rol de quien hizo el comentario de un producto, en el caso de ser un consumidor, se acompaa una
evaluacin del producto; valores [ como productor | como autor | como consumidor + evaluacin ] *
* relacionamiento entre Expreso y Courier *
* tipos de codificacin de la seal de video usadas en el mundo; valores [ NTSC | Pal-M | Pal-N ] *
* relacionamiento entre Cliente y Pedido *
RUT + razn social + 1{ cdigo producto + cantidad a comprar }
nmero pedido + 1{ cdigo producto + ttulo + precio + { cantidad en estado + estado producto } + cantidad
producto } + estado pedido
* define si el video cuenta o no con subttulos; valores [ con | sin ] *
* define la forma en que el cliente quiere se le despache su pedido, si es de acuerdo a disponibilidad o debe
despacharse todos los productos de una sola vez (total); valores [ disponibilidad | total ] *
[ zona nacional | zona internacional ]
* indica cul es el tipo del producto; valores [ tipo cd | tipo video | tipo libro ] *
top 100 ventas + top 100 preferencias
top 100 ventas + top 100 preferencias
1{ posicin de preferencia + ttulo + promedio evaluaciones }100
tipo producto
1{ posicin de venta + ttulo + cantidad vendida }100
top 100 ventas + top 100 preferencias
periodo + cliente + cantidad vendida CDs + cantidad valorada CDs + cantidad vendida libros + cantidad valorada libros + cantidad vendida videos + cantidad valorada videos + total valorado vendido por cliente } + total
valorado vendido
{ cdigo producto + cantidad vendida en periodo + cantidad valorada en periodo }

96

ventas por tipo producto =


ventas totales CDs =
ventas totales libros =
ventas totales videos =
video =
video a actualizar =
video modificado =
video nuevo =
videos =
volumen ventas =
zona internacional =

zona nacional =

periodo + ventas totales CDs + ventas totales libros + ventas totales videos + total valorado vendido
venta por producto + cantidad total CDs + total valorado CDs
venta por producto + cantidad total libros + total valorado libros
venta por producto + cantidad total videos + total valorado videos
* subentidad de Producto * 1{ director } + 1{ productor } + duracin + { actor } + { narrador } + subtitulos + sistema + nmero serie + nmero de unidades + resea contenidos + { sinopsis }
[ video modificado | video nuevo ]
{ director } + { productor } + ( duracin ) + { actor } + { narrador } + ( subtitulos ) + ( sistema ) + ( nmero serie )
+ ( nmero de unidades ) + ( resea contenidos ) + { sinopsis }
1{ director } + 1{ productor } + duracin + { actor } + { narrador } + subtitulos + sistema + nmero serie + nmero de unidades + resea contenidos + { sinopsis }
{ video }
ventas por tipo producto + ventas por cliente
* define las zonas internacionales de envo para los efectos de clculo del flete del pedido; valores [ 1Sudamrica | 2-Centro y Norte Amrica | 3-Europa Occidental y Africa | 4-Medio Oriente y Europa Oriental | 5Asia y Oceana ]*
* define las zonas nacionales de envo para los efectos de clculo del flete del pedido; valores [ 1-Regin Metropolitana | 2-III a IX Regiones | 3-I, II, X a XII Regiones | 4-Insular Occidental ] *

97

Modelamiento Funcional: DFD jerarquizado


Diagrama de contexto

Identificacin cesta

Identificacin cesta a nombrar


Cliente a actualizar

Identificacin producto
CLIENTES

Identificacin cesta para eliminar

Top 100 solicitado

Identificacin producto a cancelar

Identificacin pedido

Ventas por cliente

GERENCIA IIC LTDA.


Producto
comentado

Periodo

Producto
seleccionado

Ventas por tipo producto

Solicitud de compra
Categora a actualizar
Producto a actualizar
Recepcin de compra

SECCIN SOLICITUD
A PROVEEDORES

Producto a describir

CD a actualizar
Libro a actualizar

Despacho
Palabra

Productos descontinuados

Video a actualizar

Sistema Marraqueta.cl

Pedidos

Provisin a actualizar

FINANZAS

Aviso pago
Top 100 CDs
PROVEEDORES

Flete a actualizar

Producto cancelado

Top 100 libros

EMPRESAS
DE COURIER

Descripcin avanzada
Pedido cancelado

Mensaje pedido despachado


Lista productos
Status pedido
Mensaje pedido solicitado

Top 100 videos


CLIENTES

Descripcin producto
Detalle pedido
Mensaje pedido en proceso

98

Periodo

Diagrama 0

Producto cancelado

Inclusiones
Solicitud de compra

Identificacin cesta

Ventas por tipo producto


Pedido cancelado

Recepcin de compra

Mensaje pedido despachado


Ventas por cliente

Pedidos

Productos descontinuados

Mensaje pedido solicitado

2
Administrar
pedidos

Identificacin pedido

Status pedido

Despacho

Identificacin producto a cancelar

1
Procesar
pedidos

Cliente a actualizar

Detalle pedido
Clientes

Aviso pago
Mensaje pedido en proceso

Identificacin cesta
pasada a caja

Identificacin producto cancelado

Contenidos
Identificacin producto

Identificacin cesta para eliminar

5
Actualizar
empresas
asociadas

4
Administrar
cestas
Productos
Fletes

Flete a actualizar
Identificacin cesta a nombrar
Provisin a actualizar

Producto comentado
Top 100 solicitado
Lista productos
Top 100 videos

Productos
Asociados

Top 100 libros


Palabra
Top 100 CDs
Categora a actualizar

3
Administrar
productos

Producto seleccionado

Descripcin producto

Producto a describir
Producto a actualizar
Descripcin avanzada

CD a actualizar

Libro a actualizar

Video a actualizar

99

DIAGRAMA 1 - Procesar pedidos

Identificacin cesta pasada a caja


Fletes
Identificacin cesta

Contenidos
Clientes
eventuales

Mensaje pedido despachado

Detalle pedido
1.1
Pasar a caja

1.2
Despachar
pedidos

Clientes
registrados

Despacho

Mensaje pedido solicitado


Aviso pago
Productos descontinuados

Clientes
permanentes
Pedidos
Productos

Lista de despachos

1.6
Revisar stock
Clientes

Inclusiones

Reposicin de stock
1.7
Emitir
solicitud de
compra

Cliente a actualizar
1.3
Actualizar
clientes

Solicitud de compra

Mensaje pedido en proceso

Proveedores
1.8
Verificar
disponibilidad

1.4
Verificar
recepcin de Pedido en proceso
stock
Identificacin producto sin stock

1.5
Actualizar
stock

Identificacin producto cancelado


Recepcin de compra

100

Periodo

DIAGRAMA 2 - Administrar pedidos


Ventas por cliente

2.1
Generar
volmenes de
ventas por
cliente

Productos
asociados

Clientes

Productos

2.2
Actualizar
productos
asociados

2.3
Generar
volumen de
ventas por
tipo producto
Pedidos

Inclusiones

Ventas por tipo producto

2.4
Consultar
pedido

2.5
Actualizar
rankings

Identificacin pedido
Identificacin producto a cancelar

Pedido cancelado

2.6
Cancelar
producto

Status pedido

Producto cancelado
Identificacin producto cancelado

101

DIAGRAMA 3 - Administrar productos

Categora a actualizar
Descripcin producto
3.1
Actualizar
categoras
Categoras
Producto seleccionado
3.2
Describir
producto

Producto a actualizar

Libros

Palabra

CD a actualizar
3.3
Buscar
producto
CD's

Lista productos

3.4
Actualizar
productos

Top 100 solicitado

Video a actualizar

Videos
Top 100 CDs
Libro a actualizar
3.5
Consultar
top 100
Top 100 libros

Productos
3.7
Describir
ms del
producto

Top 100 videos

3.6
Agregar
comentarios
Producto comentado

Productos
asociados
Descripcin avanzada

Producto a describir

102

DIAGRAMA 4 - Administrar cestas


Contenidos
Identificacin cesta para eliminar

Identificacin producto

Identificacin cesta pasada a caja


4.2
Eliminar
cesta

4.1
Agregar
producto a
cesta
Productos

Cestas

Identificacin cesta a nombrar

Clientes
4.3
Asignar
nombre a
cesta

DIAGRAMA 5 - Actualizar empresas asociadas

Flete a actualizar

Provisin a actualizar
Fletes

5.1
Actualizar
provisin

5.2
Actualizar
fletes
Empresas

Modelamiento Funcional: EP en documento anexo

103

S-ar putea să vă placă și