Tutorial given by Prof. J. Guerrero-Garcia at ENC'2012 conference

1. Tutorial on Information
Systems for Bussiness Process
Dra. Josefina Guerrero García
Dr. Juan Manuel González Calleros
Facultad de Ciencias de la Computación
Benemérita Universidad Autónoma de Puebla
Ciudad Universitaria
Av. San Claudio y 14 sur, Edificio 136ª
Puebla, México.
Email: juan.gonzalez@cs.buap.mx
jguerrero@cs.buap.mx
Twitter: @Juan__Gonzalez

2. Los procesos
• Un proceso es un conjunto de actividades o eventos
(coordinados u organizados) que se realizan o
suceden (alternativa o simultáneamente)bajo ciertas
circunstancias con un fin determinado.
• La definición de un proceso indica el ordenamiento de
tareas en tiempo, espacio, y recursos.
– Relación directa con las tareas de alto nivel
– Nos permite determinar lo que se requiere y no entrar en
los detalles (modelo de tareas)
• Para modelar problema más extensos y complejos
1-2
@Juan__Gonzalez

3. ¿Por qué modelar procesos?
• Dan soporte a los procesos de negocios cuando
son automatizados usando Workflow
– Requisito necesario para permanecer competitivo
• Workflow se refiere a los procesos de negocio que
pueden ser automatizados
– En particular nos interesan aquellos que usan
sistemas basados en computadoras
• El modelado de procesos usando Workflows
permite ladefinici{on de tareas de alto nivel, las
cuales pueden ser detalladas con modelos de
tareas
1-3
@Juan__Gonzalez

4. ¿Por qué modelar procesos?
• A pesar de que los sistemas de información se
consideran vitales en una organización no
necesariamente cumplen con tales expectativas en
la practica.
– Las tareas son definidas asumiendo que serán
ejecutadas por personas
– La estructura organizacional define grupos de
usuarios
– Después se determina si se requieren sistemas para
apoyarlos en sus actividades
 Los sistemas no logran sus objetivos
1-4
@Juan__Gonzalez

5. ¿Por qué modelar procesos?
• Es importante construir Sistemas con éxito
es, al menos por dos razones:
– 1) para lograr exitio un SI debe ser
comprensible para las organizaciones y solo
puede ser posible si tiene en cuenta prácticas
actuales de trabajo,
– 2) un SI determina, en cierto grado , qué trabajo
se puede hacer y cómo puede llevarse a cabo,
• debe ser diseñado de acuerdo a los objetivos y metas
de las organizaciones
1-5
@Juan__Gonzalez

6. Modelando Procesos
• Workflow define las actividades relacionadas con la
ejecución coordinada de múltiples tareas realizadas
por los diferentes recursos para lograr un objetivo
comercial común.
– Una de las tareas define el trabajo que hacer por una
persona, por un sistema de software o por ambos.
– Para controlar y coordinar la ejecución de tareas
tenemos que conocer quienes las deben ejecutar bajo
que condiciones y donde, así como las relaciones
entre las propias tareas.
1-6
@Juan__Gonzalez

7. Modelando Procesos – Lo que
buscamos modelar
1-7
@Juan__Gonzalez

8. Modelando Procesos – Lo que
buscamos modelar
1-8
@Juan__Gonzalez

9. Modelando Procesos – Lo que buscamos
modelar
1-9
@Juan__Gonzalez

10. Beneficios del modelado de procesos
– Adherencia a los procesos de modelos
(compatible)
– Explicita representación de control del flujo
del trabajo
• Cambios al modelado de procesos no
requiere esfuerzo de codificación
– Explicita representación del envolvimiento de
los recursos
• Trabajo es directamente ruteado hacia el
recurso correcto
• Aspectos como carga de trabajo, historial,
entre otros, pueden ser tomados en cuenta
en la asignación de trabajo 1-10
@Juan__Gonzalez

11. Ciclo de vida del modelado de procesos
Diagnostico
diagnosis
process process
(Re)Dise
Mejora de
enactment (re)design
ño de
procesos y
and
monitoreo
and
procesos
monitoring yanalysis
análisis
system
Configuración
configuration
del sistema
1-11
@Juan__Gonzalez

12. Donde todo inicia
EL CONCEPTO DE TAREA
1-12

13. 1. El concepto de tarea
– Esta es una tarea
• Incribirse a un peridico a traves de un formulario
• Pedir un libro
• Validar un plano con un urbanista cara a cara
– Esta no es una tarea
• Garantizar la distribución de periodicos
– Tarea Interactiva = tarea de usuario
• Exemples:
–  Guardar una solicitu de compra
–  Imprimir el correo de forma masiva
1-13
@Juan__Gonzalez

14. El concepto de tarea
• Ciclo simplificado de tareas
Task
suspended
Task start
offer suspend
offered resume
Task run, redo Task finish Task
define Task start
created started undo, repeat completed review finished
start
Task
allocate
allocated
delegate cancel fail
return
Task Task
Task cancelled failed
delegated
1-14
@Juan__Gonzalez

15. Ciclo de vida estándar de una tarea
• Creación
– Resulta de identificar el objetivo operacional que la define
• Afectación a un actor
– El actor se convierte en responsable de la tarea
• Lanzamiento
– Una vez que las condiciones se dan se lanza la tarea
• Toma de responsabilidad
– Inicio de la realización efectiva de la tarea
• Terminación
– Momento donde el objetivo de la tarea se ha cumplido
• Destrucción
– Supresión de referencias en situaciones de cooperación
1-15
@Juan__Gonzalez

16. 1. Concepto de tarea
• Definición
– Tratamiento de una unidad de ejecución espacio-
temporal en una unidad organizacional usando el
mismo conjunto de recursos
• ¿Cómo identificar tareas?
– Criterios de identificación
1-16
@Juan__Gonzalez

17. 1. Concepto de tarea
• Criterios de identificación
• Cambio de unidad espacial (inter
organización/manual/auto/mecánica)
– reubicación
estación de trabajo
otro lugar (oficina general / sucursal)
• Cambio de recurso
Persona: + experto en finanzas
Hardware: Pocket PC +, - terminal
Información: Cliente -> Producto
• Cambio de unidad temporal
– Existencia de una interrupción
existencia de un punto de espera
Tipo de decisión: Si la opción es correcta
– Tipo de acumulador: para cada permanencia en la unidad de
implementación
– Cambio en la frecuencia de ejecución
1-17
@Juan__Gonzalez

18. 1. Concepto de tarea
– Ejemplo : « Tratamiento de ordenes del
cliente »
-Punto de • 1. Preparación de la orden
espera – Tarea manual
-Punto de
decisión – Abrir sobres, verificar la orden de compra que este
-Cambio de debidamente firmada y contenga la información necesaria
recurso para identificar al cliente
• 2. Registro de la Orden
– Tarea interactiva
– El operador de registros debe, via una terminal de trabajo,
codificar los dato de la orden. 1-18
@Juan__Gonzalez

19. 1. Concepto de tarea
• Ejemplo: « Tratamiento de ordenes del
cliente »
2. Registro de la Orden
-Punto de
decisión • 3. Preparación de una solicitud
-Cambio de – Tarea automática
recurso
– Actualiza el inventario de productos asocia a la
orden. Algunas cosas de la solicitud dan origen a
Punto de espera solicitud de compras, el resto es guardado y será
enviado en uno o más envíos.
• 4. Preparación de la entrega
– Tarea automática
– Cuando n solicitudes han sido generadas, se procede
con la preparación de los envíos de manera que se
optimizan los recursos 1-19
@Juan__Gonzalez

20. 1. Concepto de tarea
• Ejemplo: « Tratamiento de ordenes del
cliente »
-Cambio
de recurso • 4. Preparación del envío
-Cambio
de lugar
-Cambio de • 5. Tratamiento del pedido
recurso
– Tarea manual
– Cruzar la bodega recolectando los productos
• 6. Elaboración del paquete
– Tarea interactiva
– Al final de la recolección de cosas se colocan en una
maquina que empaqueta, ahí mismo se envia a
imprimir el recibo, factura y los documentos de envío 1-20
@Juan__Gonzalez

21. 1. Concepto de tarea
• Ejemplo: « Tratamiento de ordenes del cliente »
– 6. Elaboración del paquete
-Cambio
de
recurso
• 7. Envío de mercancía
– Tarea manual
-Diferencia de – El paquete y los docs de acompañamiento (o prueba de no
periodicidad
entrega) son enviados al cliente.
• 8. Selección de ordenes retrasadas
– Automática
– Cuando llega mercancía, entregas retrasadas de estos
productos son seleccionadas
1-21
@Juan__Gonzalez

22. 1. Concepto de tarea
• Ejemplo: « Tratamiento de ordenes del cliente »
– 8. Selección de ordenes retrasadas
-Diferencia de
periodicidad
• 9. Notificación de no reservas
– Tarea automática
– Cada vez que el producto se ha terminado una
notificación se hace al cliente
1-22
@Juan__Gonzalez

23. Tabla de Identificación de Tareas
– Presentación estándar de las tareas
N° Nom de la tarea Pred Definición Justificación Naturaleza
1 Hacer un _ Ccrear un expediente Manual
expediente Len la sucural
– N° = número de la tarea en la aplicación
– Nom de la tarea = nombre de la tarea, verbo objeto
afectado por la acción
– Pred = no predecesor de la tarea
– Definición = descripción detallada de la tarea
– Justificación = lista de criterios de identificación de la
tarea
– Naturaleza = manual, interactiva, automática o
abstracta
1-23
@Juan__Gonzalez

24. 1. Concepto de tarea
• Criterios de identificacion («Trucos»)
– Para descubrir una tarea
• Cambio de lugar
– recorrido, cambio de lugar en la sucursal, cambio de oficina, ir a
otro puesto de trabajo
• Cambio de recurso
– de tipo de persona : una a otra persona
– de tipo material :
» Todo cambio de materia prima (man/int/auto/méca)
» terminal, impresora, red Internet
– de tipe informacional : otro tipo de expediente
• Punto de espara de tipo decisión
– Decisión humana
– Línea correcta, ccompra registrada, si…, acceptada, podría ser en
caso de …, aprueba
1-24
@Juan__Gonzalez

25. 1-25
@Juan__Gonzalez

26. 1. Concepto de tarea
• Criterios de identificacion («Trucos»)
– Para descubrir una tarea
• Punto de espera tipo acumulación
– Ara da producto, una vez que llega todo, esperamos un
paquete para enviar, enviar despues de que llegan 10
paquetes
• Diferencia de periodicidad
– A cada re aprovisionamiento – cada que un producto esta
disponible
– A terminar la semana – al menos 20 minutos de espera
1-26
@Juan__Gonzalez

27. 1. Concepto de tarea
• Criterios de identificación («Trucos»)
– Para descubrir una tarea
• No-permanencia en la unidad de ejecución en
ejecuciones sucesivas
Tâche A Tâche D Si C depende logicamente de A y B
Donde la ejecución es asincrna
Tâche C , entonces C es una tarea
Tâche B Tâche E
• Punto de espera
– Ya que, cuando, enseguida, el fin de…, es seguido de …,
inicia, después, en la recepción de
– Mensaje de hora : son 5 horas 1-27
@Juan__Gonzalez

28. Elicitación de requerimientos
HERRAMIENTA DE
IDENTIFICACIÓN DE TAREAS
1-28

29. Tool support
• Herramienta para la identificación de
tareas
29 HCIS’2008 – Milan, September 8-9th, 2008, during IFIP World 1-29
Congress 2008
@Juan__Gonzalez

30. Nivel : clasificación manual
• Definición :
– El usuario del programa hace el trabajo de
elicitación
– Sin la ayuda de un proceso automatizado
• Método :
– Selección de una zona de texto de un
escenario
– Seleccionar el modelo apropiado y el tipo de
objetos
1-30
@Juan__Gonzalez

31. Nivel : clasificación manual
1
2
3
1-31
@Juan__Gonzalez

32. Nivel : clasificación manual
• Ventajas :
– Resultados asegurados
– Más fácil de implementar que una herramienta
automatizada
– No hay necesidad de datos de clasificación
• Inconvenientes :
– Fastidiosa para el usuario
– Costoso en tiempo
1-32
@Juan__Gonzalez

33. 1. Identificación de tareas
1-33
@Juan__Gonzalez

34. 1. Concepto de tarea
• Ejercicio – Identifica y lista las tareas
Cuando un cliente llega a la agencia inmobiliaria, ingresa su solicitud a la secretaria de
solicitudes. Indica el tipo de bien que desea renta o comprar, sus restricciones de presupuesto
así como las principales características de los bienes que le podrían interesar.
El empleado registra su solicitud, es decir, asocia el perfil del cliente con las variable estándar
de comprar de bienes, en caso de ser nuevo cliente se da de alta su perfil en el sistema.
La conclusión del registro de una solicitud lanza de manera automática, para cada variante del
perfil del cliente, la impresión de bienes que pudieran ser de su interés y que aún estén
disponibles (esta lista describe la ubicación del bien, el precio solicitado y la información de la
superficie)
El cliente examina las listas y elimina lo que no le interesa. Si quedan cosas de su interés
entonces se le dirige al servicio de visitas.
Para cada bien que le interesa al cliente, se le proporcionan más amplios detalles, mientras otro
empleado busca fotografías del bien. Gracias a los detalles extras y las fotos, el cliente puede
tener una opinión más amplia del bien. El empleado registra si el cliente esta o no de acuerdo y
procede a la visita física del inmueble.
1-34
@Juan__Gonzalez

35. MODELADO DE TAREAS
1-35

36. Modelado de tareas
• Los modelos de tareas describen las actividades del
usuario para alcanzar sus metas
• Conocer las tareas necesarias para la consecución
de objetivos es fundamental para el proceso de
diseño (sobre todo si pensamos en sistemas de
información como solución).
• Si nos dieron a los desarrolladores sólo
representaciones informales (como los escenarios o
en papel maquetas), que tendrían que tomar muchas
decisiones de diseño por su propia cuenta,
probablemente sin los antecedentes necesarios, para
obtener un sistema interactivo completo.
1-36
@Juan__Gonzalez

37. Modelado de tareas
• Modelos de tareas representan la intersección
entre el diseño de la interfaz de usuario y
enfoques más sistemáticos por dar a los
diseñadores un medio de representación y
manipulación de una abstracción de las
actividades que debe realizar para alcanzar los
objetivos del usuario.
• En algunos casos el modelo de tarea de un
sistema existente se crea con el fin de entender
mejor el diseño subyacente y analizar sus
posibles limitaciones y cómo superarlas.
1-37
@Juan__Gonzalez

38. Modelado de tareas
• El propósito es indicar cómo las actividades
se deben realizar para obtener un nuevo
sistema, usable que es apoyado por una
nueva tecnología.
• Modelos de tareas pueden ser representados
en diferentes niveles de abstracción.:
– Alto nivel: las actividades de las principales tareas
– Bajo nivel: las actividades se representan con una
granularidad pequeña, todos los detalles.
1-38
@Juan__Gonzalez

39. Modelado de tareas
• El modelo puede ser una aplicación completa o
una de sus partes.
– los diseñadores quieren modelar algunas sub-
conjuntos con el fin de analizar e identificar las
posibles opciones de diseño y las mejores soluciones.
• Cuanto mayor sea el conjunto de funcionalidades
consideradas, más difícil el trabajo de modelado.
• Existen herramientas que facilitan la labor del
modelado
1-39
@Juan__Gonzalez

40. Modelado de tareas
• Modelos de tareas se puede utilizar para muchos
tipos de aplicaciones:
– Hay aplicaciones que son claramente orientado a los
objetivos y lo que las tareas están claramente
estructurados,
– otras aplicaciones de soporte a una amplia gama de
opciones disponibles en cualquier momento, con la
posibilidad constante de que los usuarios
libremente decidan qué hacer y cómo hacerlo, en este
caso el modelo de tarea no debe ser muy
estructurado a fin de que tales posibilidades.
1-40
@Juan__Gonzalez

41. Modelado de tareas
• Muchos de los modelos de trabajo, los
métodos de trabajo de análisis y
herramientas de apoyo se han introducido
en la literatura y son ampliamente
utilizados en la práctica.
• A continuación listaremos algunos de los
enfoques más usados en la literatura.
1-41
@Juan__Gonzalez

42. Herramientas para el modelado de tareas
• Muchas notaciones existen para modelar tareas
– Flexibles y expresivas
– Con información sistemática de cómo usar la
información en el modelado de tareas
– Diferentes niveles de detalle
– Diferentes operadores y relaciones
– Diferentes representaciones gráficas
• Al final la mayoría converge a una solución muy similar
• Disponibilidad de herramientas para hacer el trabajo más
fácil
1-42
@Juan__Gonzalez

43. Uso de modelos de tareas
• Mejor comprensión de la aplicación (y de su uso
en particular)
• Registro de discusiones (multidisciplinario)
• Ayuda al diseño
• Ayuda a la evaluación de usabilidad
• Ayuda a la evaluación de rendimiento
• Ayuda al usuario a ejecutar tareas (ayuda
contextual)
• Documentación (contenido + estructura)
1-43
@Juan__Gonzalez

44. Análisis de tareas
• El análisis de tareas consiste en el estudio de:
– Información que necesita el usuario para realizar la tarea (qué
hacer)
– Terminología y símbolos del dominio del problema (elementos)
– Descripción de cómo esas tareas se realizan actualmente
(cómo)
• Es el proceso de analizar la manera en que las
personas realizan sus trabajos
– Lo que hacen
– Sobre qué cosas actúan
– Qué necesitan saber
1-44
@Juan__Gonzalez

45. Estandar Ansi-Cea
 Según estudios, la mitad de los productos
electrónicos de consumo devueltos a la
tienda funcionan al 100% - los clientes
simplemente no pudieron averiguar como
operarlos.
1-45

46. La crisis de usabilidad tiene al menos dos
aspectos:
 Complejidad
 Inconsistencia
1-46

47. Complejidad
 El control por computadora a hecho fácil
poder agregarle características a los
productos.
 Como resultado a provocado que los
usuarios no puedan manejar
intuitivamente los diseños de la interfaz de
usuario.
1-47

48. Inconsistencia
 La diferencia que existe entre las
interfaces de dispositivos con funciones
similares o del mismo fabricante.
1-48

49. ANSI/CEA-2018
 La aprobación del estándar ANSI/CEA-
2018 fue motivada precisamente por la
crisis de usabilidad en los productos
electrónicos controlados por computadora.
1-49

50. Interfaz de usuario basada en tareas
 Una manera de reducir la complejidad es
eliminando el mayor número de
características como sea posible.
 Apple ha sido notable por hacer esto.
1-50

51. Referencias
 Building Task-Based User Interfaces with
ANSI/CEA-2018, Charles Rich, Worcester
Polytechnic Institute, IEEE Computer, Vol.
42
 [Implementación ANSI/CEA-2018]
http://www.cs.wpi.edu/~rich/cetask
 [Implementación GUI]
http://www.cs.wpi.edu/~rich/courses/cs525
u-s08/projects 1-51

52. ConcurTaskTrees
• Estructura jerárquica de las tareas
• Sintaxis es gráfica
– Facilita su uso y comprensión
• Se centra en las actividades del usuario
• Se crea en 3 niveles
– Descomposición de las tares
– Definición de las relaciones espacio-temporales de las
tareas
– Asociación de objetos para la ejecución de tareas
• Interfaz de usuario
• Datos de dominio de la aplicación
1-52
@Juan__Gonzalez

53. ConcurTaskTrees
• Cada tarea se especifica con:
– Identificador
– Nombre
– Categoría
– Tipo
– Frecuencia de uso
– Plataforma donde se usa
– Anotaciones informales
– Precondiciones
1-53
@Juan__Gonzalez

54. ConcurTaskTrees: Las categorías
Interaccíón
Aplicación
Usuario
Abstracta
Cooperativa 1-54

55. ConcurTaskTrees: operadores
temporales
• T1 >> T2 habilitar
• T1 [ ]>> T2 habilitar + paso de información
• T1 |> T2 suspender / resumir
• T1 [ ] T2 Selección
• T1 [> T2 Deshabilitar
• T1 |=| T2 Independencia (cualquier orden)
• T1* Iteración
• T1{n} Iteración finita
• T1 ||| T2 Concurrencia
• T1 |[x]| T2 Concurrencia + paso información
• [T] Opcional
• T Recursión
1-55
@Juan__Gonzalez

56. T1 T2
Time
1-56
@Juan__Gonzalez

57. T1
T2
Time
1-57
@Juan__Gonzalez

58. T2
T1
T1
T2
Time
1-58
@Juan__Gonzalez

59. T1 T2
T2 T1
Time
1-59
@Juan__Gonzalez

60. T1
T2
Time
1-60
@Juan__Gonzalez

61. T1 T1
T2
Time
1-61
@Juan__Gonzalez

62. T1 T2
Time
1-62
@Juan__Gonzalez

63. T2
T1
T1
T2
Time
1-63
@Juan__Gonzalez

64. Operadores temporales
• * Iteración. La tarea es ejecutada repetidamente. Esto
se repite tantas veces como sea necesario y solo hasta
que otra tarea la desactiva.
T1 T2
1-64
@Juan__Gonzalez

65. Operadores temporales
• * Iteración finita. La tarea es ejecutada
repetidamente n cantidad de veces. La cantidad
de repeticiones depende del problema.
N veces
T1 T2
1-65
@Juan__Gonzalez

66. Operadores temporales
• [] tarea opcional. Indica la posibilidad de
que una tarea no sea ejecutada.
1-66
@Juan__Gonzalez

67. Operadores temporales
• Recursión. Cuando una tarea ya defina
puede ser reusada en otra parte del árbol
de tareas..
1-67
@Juan__Gonzalez

68. Ejemplo
• Uso de un teléfono celular, tareas de alto
nivel
1-68
@Juan__Gonzalez

69. Ejemplo
• Uso de un teléfono celular, nivel
intermedio
1-69
@Juan__Gonzalez

70. Ejemplo
• Uso de un teléfono celular, bajo nivel
intermedio
1-70
@Juan__Gonzalez

71. Ejemplo
• Uso de un teléfono celular, nivel
intermedio
1-71
@Juan__Gonzalez

72. Ejemplo
• Uso de un teléfono celular, bajo nivel
1-72
@Juan__Gonzalez

73. Ejemplo
• Uso de un teléfono celular, tareas de alto
nivel
1-73
@Juan__Gonzalez

74. Ejemplo
• Uso de un teléfono celular, bajo nivel
1-74
@Juan__Gonzalez

75. Recomendaciones al modelar tareas
• Nombre de la tarea: Usa la nomenclatura
– Tipo de tarea + Objeto que manipula
1-75
@Juan__Gonzalez

76. Recomendaciones al modelar tareas
• Nombre de la tarea: Usa la nomenclatura
– Tipo de tarea + Objeto que manipula
1-76
@Juan__Gonzalez

77. Recomendaciones al modelar tareas
• Nombre de la tarea: Usa la nomenclatura
– Tipo de tarea + Objeto que manipula
1-77
@Juan__Gonzalez

78. Recomendaciones al modelar tareas
• Nombre de la tarea: Usa la nomenclatura
– Tipo de tarea + Objeto que manipula
Items de tarea Definición
Colección Especifica la manipulación de un conjunto de
items de tareas
Contenedor Especifica un item que agrupa o acumular otros
items de tareas
Element o Es el item que representa un característica simple
Operation Especifica una función
1-78
@Juan__Gonzalez

79. Recomendaciones al modelar tareas
• Nombre de la tarea: Usa la nomenclatura
– Tipo de tarea + Objeto que manipula
1-79
@Juan__Gonzalez

80. Recomendaciones al modelar tareas
• Evitar la ambigüedad
Cual es el orden de ejecución de estas tareas?
T2, (T3 y T4), Si T4 es ejecutada
puedo ejecutar T5 ¿Esto es
correcto? ¿T3 es alcanzable? 1-80
@Juan__Gonzalez

81. Recomendaciones al modelar tareas
• Evitar la ambigüedad
La ejecución ahora es clara
T2, (T3 y T4), T5 o T6
1-81
@Juan__Gonzalez

82. El modelo de tareas es
independiente de la herramienta
1-82
@Juan__Gonzalez

83. Ejercicio
• Hacer el modelo de un ATM
– Pensar en las actividades normales
– Pensar en las actividades anormales
• Algunas restricciones
– Insertar_Tarjeta, Ingresar Codigo Pin, Retirar
tarjeta
– Solicitar retiro, Seleccionar cantidad, Retirar
efectivo
– Etc… 1-83
@Juan__Gonzalez

84. ATM: Tarea Categories Operators
• Meta: obtener • T1 >> T2 habilitar
dinero, pagar tarjeta • T1 [ ]>> T2 habilitar +
de crédito, consulta paso de información
de saldo Interaction T1 |> T2 suspender /
•
• Prerequisitos: resumir
– Tener tarjeta • T1 [ ] T2 Selección
– Conocer cantidar a •
retirar Application T1 [> T2 Deshabilitar
• T1 |=| T2 Independencia
– Conocer número pin (cualquier orden)
– Conocer no de • T1* Iteración
cuenta de tarjeta de User • T1{n} Iteración finita
credito
• T1 ||| T2 Concurrencia
• Resultados • T1 |[x]| T2 Concurrencia +
– Retiro de dinero paso información
– Tarjeta en mano Abstract • [T] Opcional
– Comprobante de • T Recursión 1-84
pago a tarjeta
– Saldo de la tarjeta @Juan__Gonzalez

85. PROCESOS
1-85

86. Un árbol puede ser muy extenso
List Meter
[ ]>> [ ]>>
Selection Visualization Operations on instances
|||| |||| ||||
Selection Order Zone ... Last Actions Navigation
name Reading
[ ]>> [ ]>>
[ ]>> [ ]>> [ ]>>
Process Process Actions Instance Press Navigate
Filter Meter Order Instance
filter Selection Button
Selection
[] []
[] |||
New ... Last ...
All Meter's Zone Serial Subscriber Calibre
Meter Reading
Address Code Number
||| |||
Client Zone Address Number
1-86
@Juan__Gonzalez

87. División de Tareas
Time Space (location) User Stereotype
Workflow Series of time periods Different locations Different groups of resources
Process Series of time periods Same location One resource or a group of resources
Task Same time period Same location Same resource
1-87
@Juan__Gonzalez

88. Diseño de Sistemas de Workflow
1-88
@Juan__Gonzalez

89. Modelando Procesos
• UML Diagramas de actividad
– OMG
– Version 2.0 inspirado en redes de Petri
• El concepto de lugar (place) hace falta (por lo tanto no
es posible describir ciertos escenarios)
• No hay un mapeo directo
• No hay semántica simeple ni clara
– No es su intención que sea ejecutable
– No hay formalización
– Notación prácticamente no usada ya que se
adopta la notación BPMN
1-89
@Juan__Gonzalez

90. Organizando workflows
• La gente trabaja para vivir
– Estamos organizados como unidades de negocio
especializados
– Limitado rango de productos
– Implica nuevos tipos de trabajo: trabajo creado
– Los empleados necesitan entender para que cliente estan
trabajando
• Proceso de negocio
– Caso= todos los tipos de trabajo = trabajo,
empleo, producto, servicio, elemento
• Abstracto o concreto
• Discreto por naturaleza: delimitado en el tiempo
1-90
@Juan__Gonzalez

91. Organizando workflows
• Cada caso involucra un proceso
– Un proceso consiste de
• Una serie de tareas que requieren ser ejecutadas
• Un conjunto de condiciones que determinan el orden de las
tareas
• Es igual a un procedimiento
– Una tarea es la unidad logica de trabajo que es ejecutada
individualmente por un recurso
• Ejecución <> responsabilidad
– Orden de tareas = diagrama de procesos
= n predecesores, 1 sucesor = 1 predecesor, n sucesores
1-91
@Juan__Gonzalez

92. Organizando workflows
• Una tarea en una proceso representa tareas de
alto nivel las cuales pueden ser detalladas
usando modelos de tareas
– Un modelo de tareas es asociado
• Un proceso es ejecutado por cada caso
– La ejecución de una tarea por un recurso es
llamado actividad
• Varios casos podrían usar el mismo proceso
pero cada caso seguirá su propia ruta
– Depende de los atributos del caso 1-92
@Juan__Gonzalez

93. Definición de proceso
• La definición de un proceso especifica que pasos son
requeridos y en que orden deben ser ejecutados.
– (enrutamiento, definición, procedimiento, workflow
script)
– (orden de compra, declaración de impuestos, proceso
de reclamación de seguro)
• La definición de un procesos consiste de:
– Tareas (paso, actividad, elemento del proceso)
– Una tarea es de alto nivel y puede descomponerse en
subtareas.
– Condiciones (estado, fase, requirimiento)
– Una condición es usada para determinar las tareas
que esán disponibles.
1-93
@Juan__Gonzalez

94. Caso
• Un caso es la ‘cosa' que requiere ser procesada
siguiendo la definición del proceso.
– (instancia de un proceso, job, projecto)
– (reclamo de seguro, orden de compra, queja,
aplicación de prestamo)
• El estado de un caso esta determinado por:
– Variables del caso (parámetros del caso)
– Los atributos lógicos del caso que son usados
para direccionar el caso.
– Condiciones
– Los requerimientos que son satisfechos.
• Datos de la aplicación están fuera del modelado de
procesos.
1-94
@Juan__Gonzalez

95. Modelando Procesos
•La notación esta inspirada en las redes de Petri
•Definido por Carl Adam Petri en los años sesenta
•Teoría formal para el modelado de concurrencia
(varias actividades, varias personas, juntos o
separados)
•Grafo bipartito formado por los
lugares/places (representados por círculos) y
transiciones (representadas por las barras o cajas)
place transition arc 1-95
@Juan__Gonzalez

96. Modelando Procesos
tarea condición
caso
List Meter
Detalle de tarea Selection
[ ]>>
Visualization
[ ]>>
Operations on instances
|||| |||| ||||
Selection Order Zone ... Last Actions Navigation
name Reading
[ ]>> [ ]>>
[ ]>> [ ]>> [ ]>>
Process Process Actions Instance Press Navigate
Filter Meter Order Instance
filter Selection Button
Selection
[] []
[] |||
New ... Last ...
All Meter's Zone Serial Subscriber Calibre
Meter Reading
Address Code Number 1-96
||| |||
Client Zone Address Number
@Juan__Gonzalez

97. Red de Petri de un proceso de reclamación
de intervención de aseguradora de autos
Reparar auto
Manejar cuenta
Obtener cotización
Comprar auto nuevo
Presentar reclamación
Final de seguro
preliminares
de reclamación de seguros
1-97
Nota: Tareas de alto nivel
@Juan__Gonzalez

98. Habilitando las transiciones
• Las transiciones cambian los estados de la
red al ser ejecutadas.
• Solo las transiciones habilitadas pueden ser
ejecutadas.
• Informalmente, una transición esta
habilitada si todos los estados reueridos
para su ejecución contienen al menos un
token.
1-98
@Juan__Gonzalez

99. Ejecución de una transición: Ejemplo
Antes
1-99
@Juan__Gonzalez

100. Ejecución de una transición: Ejemplo
Antes
1-100
@Juan__Gonzalez

101. Ejecución de una transición: Ejemplo
Antes Después
1-101
@Juan__Gonzalez

102. Ejecución de una transición: Ejemplos
1-102
@Juan__Gonzalez

103. Ejemplo concreto
Deposito de dulces Listo para deposito de moneda
Insertar moneda
rellenar
Entregar dulce
Rechazar moneda
Retener moneda
Aceptar moneda
Solicitar relleno Listo a entregar
1-103
@Juan__Gonzalez

104. Ejemplo concreto Única
transición
Deposito de dulces Listo para deposito de moneda disponible
Insertar moneda
rellenar
Entregar dulce
Rechazar moneda
Retener moneda
Aceptar moneda
Solicitar relleno Listo a entregar
1-104
@Juan__Gonzalez

105. Ejemplo concreto
Deposito de dulces Listo para deposito de moneda
Insertar moneda
Transiciones
disponibles
rellenar
Entregar dulce
Rechazar moneda
Retener moneda
Aceptar moneda
Solicitar relleno Listo a entregar
1-105
@Juan__Gonzalez

106. Rechazar la
moneda me
Ejemplo concreto regresa al
estado inicial
Deposito de dulces Listo para deposito de moneda
Insertar moneda
rellenar
Entregar dulce
Rechazar moneda
Retener moneda
Aceptar moneda
Solicitar relleno Listo a entregar
1-106
@Juan__Gonzalez

107. Ejemplo concreto
Deposito de dulces Listo para deposito de moneda
Insertar moneda
Aceptar la
moneda
rellenar
Entregar dulce
Rechazar moneda
Retener moneda
Aceptar moneda
Solicitar relleno Listo a entregar
1-107
@Juan__Gonzalez

108. Ejemplo concreto
Deposito de dulces Listo para deposito de moneda
Listo para Insertar moneda
entregar
dulce
rellenar
Entregar dulce
Rechazar moneda
Retener moneda
Aceptar moneda
Solicitar relleno Listo a entregar
1-108
@Juan__Gonzalez

109. Listo para
recibir
Ejemplo concreto moneda
Deposito de dulces Listo para deposito de moneda
Insertar moneda
rellenar
Entregar dulce
Rechazar moneda
Retener moneda
Listo para Aceptar moneda
rellenar
maquina
Solicitar relleno Listo a entregar
1-109
@Juan__Gonzalez

110. Listo para
No recibir
necesariamente
se abastase
Ejemplo concreto moneda
inmediatamente
Deposito de dulces Listo para deposito de moneda
Insertar moneda
rellenar
Entregar dulce
Rechazar moneda
Retener moneda
Aceptar moneda
Solicitar relleno Listo a entregar
1-110
@Juan__Gonzalez

111. Otro ejemplo de red de Petri: Elevador 1
El número de tokens representa el número de movimientos verticales que puede h
1-111
elevador hacia arriba o abajo en cualquier estado del sistema
Animation by Wil van der Aalst, Vincent Almering and Herman Wijbenga
@Juan__Gonzalez

112. Otro ejemplo de red de Petri:
Elevador 2
El token representa el elevador y sus posibles estados estan representados
1-112
pisosP1 a P4 y las transiciones A1 a A6 el ascenso o descenso del elevador
Animation by Wil van der@Juan__Gonzalez
Aalst, Vincent Almering and Herman Wijbenga

113. Otro ejemplo de red de Petri: Elevador 3
El token representa la persona que usa al elevador y sus tareas denotadas d
1-113
A1 a A4
Animation by Wil van der@Juan__Gonzalez
Aalst, Vincent Almering and Herman Wijbenga

114. Ejercicio de modelado
• ¿Qué aprendimos de los ejemplos anteriores?
– La perspectiva y el objeto en estudio hace que el modelado de
procesos sea diferente
• Ejercicio
– Modelar la red de Petri necesaria para controlar los semáforos de
un cruce simple, es decir, si el semáforo1 tiene luz roja ponerle luz
roja al semáforo 2.
• Modela primero un semáforo
• Después busca el estado común que relaciona los dos semáforos
1-114
@Juan__Gonzalez

115. Solución al problema de tráfico de
semáforo
Animation by Wil van der Aalst, Vincent Almering and Herman Wijbenga 1-115
@Juan__Gonzalez

116. Catalogo de Patrones
Patrones de Control Primario
• Sequence
2011 BUAP 116

117. Catalogo de Patrones
Patrones de Control Primario
• And-Split – ejecuta actividades en paralelo
• Ejemplos
• Después de la terminación de la tarea de captura de la matrícula, ejecutar
crear el perfil de los estudiantes y enviar confirmación de inscripción al
mismo tiempo.
• Cuando una alarma de intrusión se recibe, active la tarea alertar guardia e
informar inmediatamente a la policía.
Una vez el cliente haya pagado por los bienes, empaquetarlos y emitir un
recibo.
2011 BUAP 117

118. Catalogo de Patrones
Patrones de Control Primario
• And-Join – sincronizar dos hilos paralelos de ejecución
• Ejemplos
• La tarea de despacho de bienes se ejecuta inmediatamente después de
que tanto la verificar factura y producir recibo son completadas.
• La declaración de efectivo en el cajón sólo puede ocurrir cuando la
tienda ha sido cerrada y el resumen de tarjeta de crédito ha sido impreso.
2011 BUAP 118

119. Catalogo de Patrones
Patrones de Control Primario
• XOR-Split – seleccionar una ejecución de muchas alternativas
• Ejemplos
• Dependiendo del volumen de tierra para ser trasladados, se envía la
petición de la retroexcavadora, el bobcat o la excavadora-D9
para completar el trabajo.
Después de la tarea revisión de elección se haya completado, o
bien declaran los resultados o la tarea de recuento de votos se realiza.
2011 BUAP 119

120. Catalogo de Patrones
Patrones de Control Primario
• XOR-Join – une dos alternativas de ejecución
• Ejemplos
• A la conclusión de la excavación de la excavadora bobcat o la d9, la tarea
de estimación de cantidad de tierra excavada es realizada para solicitar
pago.
• Después de hacer el pago u otorgar creditos, se inicia la tarea de hacer
recibo del producto.
2011 BUAP 120

121. Catalogo de Patrones
• Or-Split – seleccione muchos caminos de ejecución de entre muchas
opciones
• Ejemplos
• Dependiendo de la naturaleza de la llamada de emergencia, una o más
tareas de envío es efectuada: enviar policía, enviar carro de bomberos y
enviar ambulancia.
2011 BUAP 121

122. Catalogo de Patrones
Patrones de Conexión y Sincronización Avanzados
• Or-Join – La unión de dos o más líneas de ejecución (que divergieron
previamente en un punto especifico) y se unen en una única línea de
consecución.
• La Unión sincronizada estructurada ocurre en un contexto estructurado, es
decir debe existir un or-split antes en el modelo de procesos.
2011 BUAP 122

123. Catalogo de Patrones
Patrones de Conexión y Sincronización Avanzados
• Or-Join
• Ejemplos
• Dependiendo la naturaleza de la llamada una o más tareas de envío es
efectuada: enviar policía, enviar carro de bomberos y enviar ambulancia.
Cuando todos los vehículos de emergencia lleguen al lugar del accidente, la
tarea transferir-paciente comienza.
2011 BUAP 123

124. Herramienta para modelado de procesos
YAWL
2011 BUAP 124

125. YAWL notación
Composite task Multiple Instance task
2011 BUAP 125

126. Ejemplo general de Yawl
Vuelo
hotel pagar
reservar
auto
2011 BUAP 126

127. Ejemplo general de Yawl
vuelo
hotel
registro pagar
auto
2011 BUAP 127

128. Ejemplo general de Yawl
planear_seg
Registro mento_itiner pagar
ario
vuelo
hotel preparar_informaci
registrar_segment
ón_
o_itirenario
pago
auto
2011 BUAP 128

129. Ejemplo General YAWL
avión pagar
hotel
registro
auto cancelar
2011 BUAP 129

130. Actividad
• Una agencia de viajes ejecuta varias tareas. Primero el cliente es
registrado. Después, el empleado busca oportunidades que son
comunicadas al cliente. Después el cliente es contactado para
determinar si sigue interesado o no en el viaje ysi quiere otras
opciones. Hay 3 posibilidades: 1) el cliente no esta interesado, 2)
quiere ver mas alternativas, 3) el cliente selecciona una
oportunidad.
• Si el cliente selecciona un viaje, el viaje es reservado. En paralelo,
uno o dos tipos de seguros (seguro de cancelación, perdida de
equipaje) se preparan si es del deseo del cliente, puede ser que
ninguno. Dos semanas antes del inicio del viaje los documentos son
enviados al cliente. Un viaje puede ser cancelado en cualquier
momento después de hacer la reservación y antes de que inicie el
viaje. Notar que los que no tengan seguro no seran reembolsados.
2011 BUAP 130

131. Ejercicio
2011 BUAP 131

132. Asignación y aceptación del
trabajo
 En el trabajo siempre estas bajo las ordenes de
otras personas
 Jefe
 Cliente
 siempre tiene la razón
 Guían nuestro trabajo
 Las ordenes del jefe a su personal
 Directas. Cuando el producto realizado es
directamente dirigido al cliente, procesos primarios
 Indirectas. Cuando el trabajo involucra
mantenimiento o mejora de los procesos de
producción, procesos secundarios y terciarios

133. Asignación y aceptación del
trabajo
 Los organigramas en una empresa sirven para
definir el orden en que una tarea es asignada de
una persona a otra.
 Los actores que intervienen en este proceso
son:
 La persona que asigna la tarea es conocido como
director; mientras que la persona a la que se le
asigna una tarea es un contratista.
 Puede ser una persona o una empresa

134. Asignación y aceptación del
trabajo
 Para tener éxito es importante:
 Tener bien claro quién es nuestro cliente
 Un empleado trabaja mejor si sabe quien es su
cliente
 Ayuda a la certidumbre sobre el potencial de lo que
hace
 Para toda relación entre director y contratista
existe una relación de trabajo o un contrato, a
veces no escrito, donde se establecen las
condiciones del producto (caso) a
desarrollarse:
 Tiempo de elaboración
 Costo

135. Asignación directa
La capacidad de especificar directamente en tiempo
de diseño la identidad de el recurso que va a
ejecutar una tarea.

136. Asignación basada en el rol
La capacidad de especificar en tiempo de diseño que
una tarea sólo puede ser ejecutada con los recursos que
desempeñan una función (rol) determinada.

137. Asignación diferida
La posibilidad de aplazar la especificación de la
identidad del recurso que ejecuta una tarea hasta el
tiempo de ejecución.

138. Asignación Aleatoria
La habilidad de ofrecer or asignar trabajos to suitable recursos on a
random basis.
 Ejemplo:
The Judge case trabajo is asignard to a Magistrate on a random basis.

139. Asignación Round Robin
 La habilidad de asignar un trabajo a recursos disponible usando ciclos
 Ejemplo:
Trabajos de revisión de artículos son asignados a los Referee usando
un ciclo.

140. Cola más corta
 La habilidad de asignar un trabajo al recurso que tiene el menor
número de trabajo asignado a él.
 Tiene como objetivo acelerar el rendimiento

141. Delegación

142. Escalada
 La habilidad de un sistema de workflow para ofrecer o asignar un
trabajo a un recurso o grupo de recursos diferente a aquel al que se
había escogido previamente vía asignación u oferta. Con el objetivo de
lograr la ejecución del trabajo, generalmente por que se ha llegado a
una fecha límite.

143. Desasignación
 La habilidad of a recurso (o grupo de recursos) a renunciar al trabajo
que es asignado a él y hacerlo disponible para la asignación a otro
recurso o grupo de recursos.

144. Reasignación con estado
La habilidad de un recurso a asignar un trabajo a otro recurso sin perdida
del valor de los datos y el estado de avance de la tareas.

145. Reasignación sin estado
 La habilidad de un recurso de reasignar un trabajo que estaba
ejecutando a otro recurso sin mantener el estado de la tarea.

146. Suspensión / Resumen
 La habilidad para un recurso para suspender y resumir la ejecución de
un trabajo.

147. Saltar
La habilidad para un recurso de saltar un trabajo asignado y marcarlo
como realizado.

148. Allocation Patterns

149. DESARROLLO DE SISTEMAS
DE INFORMACIÓN
1-149

150. Proceso
1-150
@Juan__Gonzalez

151. Marco de Referencia
1-151
@Juan__Gonzalez

152. Paso 1
1-152
@Juan__Gonzalez

153. Paso 2
1-153
@Juan__Gonzalez

154. Paso 3
1-154
@Juan__Gonzalez

155. 6. Task Modeling
Ejercicio
• Tasks in the process are detailed using task
models
155 November 9-11, 2009 - Mérida, Mexico
2011 BUAP
CLIHC’09
155

156. Ejercicio
• Attributes identified for the tasks
Task Task Type Task Item User category Facet
Insert Name Create Element Interactive Input
Insert Zip Code Create Element Interactive Input
Select Age category Select Element Interactive Input
Select Gender Select Element Interactive Input
156 November 9-11, 2009 - Mérida, Mexico
2011 BUAP
CLIHC’09
156

157. Ejemplo
User Interface Action Types Facet Specification Information to take into account Possible Abstract Interaction
Component
“create name” and “create zip Code” Create attribute value Data type, domain characteristics A text output with a text input
associated to it
“select gender and select age Select attribute value Data type, domain characteristics, A dropdown list, a group of radio
Category” + selection values selection values buttons textual or characters.
known
157 November 9-11, 2009 - Mérida, Mexico
2011 BUAP
CLIHC’09
157

158. Example of MDE of Uis in UsiXML
Total graphical VS predominant graphical
1-158
ITEA UsiXML project #08026, 2009-2012

159. Example of MDE of Uis in UsiXML
Predominant vocal VS total vocal
1-159
ITEA UsiXML project #08026, 2009-2012

160. CUI rendering in VUItoolkit
1-160

161. X3D generated from Alice
• It’s a real 3D UI!
1-161

162. FUI included in virtual scene
1-162

163. User Interface Flow
User interfaces flow
1
u1
11
2 21 22 23 24
u2
3 31
u3
2011 BUAP 163

164. User Interface Flow
2011 BUAP 164

165. Runtime Monitoring
2011 BUAP 165

166. CONCLUSIONES
1-166

167. Overview
1-167

168. Overview
Requirements Design Implementation
Conceptual
Task Workflow
models
(Ch. 3)
model model
Process
Elicitation UsiXML
model
Organiz
ational Mapping
model model
Task modeling Process modeling
Method
(Ch. 5)
Identification of
Organization Workflow Wf UI
workflow
modeling modeling definition
elements
Job and user
modeling
Workflow editor
Software
(Ch. 6)
TransformiXML
Model elicitation IdealXML GrafiXML
tool and task
spreadsheet Process editor WUIPs
.
Resource editor
.
1-168
@Juan__Gonzalez

169. Algunas reflexiones ??
• El modelado de tareas presenta una
solución que es independiente de cualquier
posible solución, incluso, computacional.
• Podemos generar interfaces de usuario a
partir de modelos de tareas ?
• Como relacionar un modelo de tareas con
otros modelos
• Los invitamos a leer la iniciativa W3C
• http://www.w3.org/2005/Incubator/model-based-ui/wiki/Main_Page
• http://www.w3.org/2005/Incubator/model-based-
ui/wiki/Task_Meta_Models
1-169
@Juan__Gonzalez

170. Join us
@usixml
http://www.facebook.com/UsiXML
1-170
BUAP
@Juan__Gonzalez

171. Thank you very much for your
attention!
User Interface eXtensible Markup Language
http://www.usixml.org
http://www.usixml.eu
Register as a member of the UsiXML End-User Club at
http://www.usixml.eu/end_user_club
Contact in Mexico
Dra. Josefina Guerrero-García jguerrero@cs.buap.mx
Dr. Juan Manuel González-Calleros juan.gonzalez@cs.buap.mx
@Juan__Gonzalez
For more information and downloading,
http://www.lilab.eu 1-171