Este documento presenta el modelo de negocios como tema de estudio. Describe las diferentes actividades de aprendizaje propuestas, incluyendo líneas de tiempo, mapas conceptuales y diagramas. Además, introduce conceptos clave como los componentes y estándares de modelado de negocios, así como ejemplos de innovación.

1. El modelo de negocio
Unidad 2

2. Actividades
• Elaborar una línea del tiempo de la evolución del modelo de negocios. (10%)
• Elaborar un mapa conceptual de los componentes del modelo de negocios.
(15%)
• Elaborar un reporte sobre diferentes modelos de negocios aplicados en
empresas reales. (15%)
• Elaborar un mapa conceptual de estándares y características. (10%)
• Elaborar ejercicios de diagramas del modelo de negocios. (20%)
• Evaluación de la unidad. (30%)

3. Introducción
• Un modelo de negocios describe la lógica sobre cómo una organización crea,
entrega y captura valor.
• Los modelos de negocios son básicamente historias que explican cómo
trabajan las organizaciones, indicando quiénes son nuestros clientes, cómo
generamos utilidades, cuál es la lógica económica subyacente que nos
permite entregar valor a los clientes a los que nos dirigimos a un costo
apropiado. Es una descripción sistémica de cómo es que las piezas de un
negocio embonan.
• El modelado de negocios, también es llamado diseño de negocio o diseño
empresarial.

4. Evolución del modelo de negocios
El modelado de negocios ha evolucionado desde los años 60 hasta la
actualidad, con el fin de convertirse en una guía de representación de una
empresa.
• Modelado de Estructuras Org.
 Son las diversas combinaciones, sistemas o modelos presentes en la estructura
orgánica que pueden llevarse a cabo en una empresa; se expresan en las cartas u
organigramas y se complementan con la descripción de puestos.
• Modelado de Flujos de Datos
 Representación gráfica de la evolución de la información dentro de un sistema de
Información.
 Desde que la información ingresa a un S.I. va sufriendo sucesivas transformaciones,
hasta que se almacena definitivamente en el sale transformada.

5. Evolución del modelo de negocios
• Modelado de Flujos de Trabajo
 Permiten abordar la automatización de los procesos que tienen lugar dentro de las
organizaciones. El desarrollo de estos sistemas ha tenido un fuerte componente
tecnológico, centrándose más en la creación de entornos de ejecución eficientes y
distribuidos, que en proporcionar un soporte formal y metodológico que garantice la
obtención de modelos de flujo de trabajo de calidad.
• Modelado de Reglas de Negocio
 Para modelar esta regla de negocio se identifican los siguientes elementos:
 Entidades involucradas: Reclamación.
 Parámetros involucrados: número de siniestro.
 Validaciones a realizar: Si número de siniestro <> nulo…
 Acción a tomar: modificar tipo de reclamación como complementaria.
 Caso alterno: Modificar tipo de reclamación como inicial.

6. Evolución del modelo de negocios
• Modelado de Objetos de Negocio
 Para crear el 6odelo de 7bjeto del 8egocio se deben utilizar los siguientes
estereotipos:
 Actor del negocio.
 Trabajador del negocio
 Unidad del negocio.
 Con estos tres estereotipos se puede desarrollar un modelo de objeto del negocio.
Este modelo identifica todos los “roles” y “cosas” en el negocio, los cuales son
representados como clases en la vista lógica.
• Modelado de Procesos de Negocio
 Cuando un proceso es modelado, con ayuda de una representación gráfica, pueden
apreciarse con facilidad las interrelaciones existentes entre distintas actividades,
analizar cada actividad, definir los puntos de contacto con otros procesos, así como
identificar los subprocesos comprendidos. Al mismo tiempo, los problemas existentes
pueden ponerse de manifiesto claramente dando la oportunidad al inicio de acciones
de mejora.

7. Evolución del modelo de negocios
• Modelado de Fines y Objetivos
 Metamodelo que define los elementos que integran un Plan de Negocios.
 Facilita el desarrollo, comunicación y gestión de planes de negocio
 Establece claras relaciones entre: o Políticas de negocios. o Reglas de negocio. o
Fines y medios de la empresa.
• Modelado de Sistemas de Negocio
• Se fundamenta en:
 La noción de Sistema de Negocios.
 El método EKD-CMM
 El método WATCH para desarrollo de software empresarial.
 Ha sido aplicado en más de 20 proyectos de desarrollo de software empresarial.
• Visto como una disciplina, el MN ha evolucionado desde sus inicios dando
énfasis a uno o más elementos de la empresa.

8. Evolución del modelo de negocios

9. Etimología y significado del "Modelado de
Negocios
• “Modelado”
• ”Formar de cera, barro u otra materia blanda una figura o adorno”
• "Acción y efecto de modelar"
• "Configurar o conformar algo no material“
• Modelado = Adquisición + Representación de Conocimientos

10. Etimología y significado del
"Modelado de Negocios
• “Negocios”
• Palabra latina formada de "nec" y "otium“
• Significa sin ocio o negación del ocio.
• Los romanos acuñaron esta palabra para referirse a una manera de ocuparse
en tiempos de paz
• Era una alternativa a la guerra, pero no era lucrativa ni aportaba gloria
• ‰
El significado actual es diferente:
• "la actividad de proveer bienes y servicios que involucra aspectos
financieros, comerciales e industriales"
• "aquello que es objeto o materia de una ocupación lucrativa o de interés"

11. Etimología y significado del
"Modelado de Negocios
• El “Modelado de Negocios” se define como un proceso de proceso de
representación de uno o más aspectos o elementos aspectos o elementos de
una empresa tales como:
• Su propósito
• Su estructura
• Su funcionalidad
• Su dinámica
• Su lógica de negocios
• Sus componentes:
 Fines, procesos de negocio, reglas de negocio, objetos de negocio, actores y unidades
organizativas.

12. Orientaciones del MN
Dominios principales en los que se emplea:
• Dominios orientados al negocio
 Gerencia
 Teoría de Organizaciones
 E-business, e-commerce
• Dominios orientados a la tecnología
 Sistemas de Información
 Ingeniería de Software
 Informática Industrial

13. Aplicaciones orientadas al negocio
• Reingeniería de Procesos
• Diseño Organizacional
• Cambio Organizacional
• Planificación Estratégica
• Desarrollo Organizacional
• Gestión del Conocimiento Organizacional

14. Aplicaciones orientadas a la tecnología
• Automatización Industrial
• Planificación y Desarrollo de Sistemas de Información
• Arquitecturas de Información Empresarial
• Integración de Aplicaciones Empresariales (EAI)
• Adaptación de aplicaciones ERP
• Comercio Electrónico y B2B
• Ingeniería de Software

15. Modelado de Negocios e Ingeniería de
Requisitos
• En el desarrollo de software, el Modelado de Negocios aporta información
esencial para la Ingeniería de Requisitos

16. Componentes del modelo
• Un buen modelo de negocio es esencial para toda organización exitosa, ya
sea que se trate de un nuevo negocio o de una empresa ya establecida. No
necesariamente estamos hablando de un modelo matemático, aunque es
posible construir un modelo en el que las relaciones entre los bloques clave
se pueden cuantificar con una relación numérica.
• Se trata más bien de una descripción que nos permite reflexionar sobre
nuestro funcionamiento e identificar alternativas innovadoras para
diferenciarnos de nuestros competidores.

17. Componentes del modelo

18. Componentes del modelo
• Estos componentes cubren las cuatro áreas principales de un negocio:
clientes, ofrecimiento, infraestructura y viabilidad financiera.
• Existe un flujo en la manera como estos bloques se identifican, analizan y
trabajan.
• La propuesta de valor es el resultado de la construcción de una
infraestructura interna (recursos y actividades claves) y de la red de valor
externa con socios alineados.
• Esta red de valor está constituida por una serie de socios claves, esto es,
proveedores de partes, componentes y de servicios como despachos de
consultoría y asesoría, firmas de ingeniería y centros de investigación,
desarrollo e innovación.

19. Componentes del modelo
• Los canales de distribución forman, en realidad, también parte de la red de
valor externa y junto con el tipo de relaciones con los clientes permiten
satisfacer las necesidades de los segmentos de mercado a los que se dirige
la organización.
• El grado en que la empresa es capaz de superar las expectativas de los
clientes, le permitirá generar la corriente de ventas que comparados con
la estructura de costos, arrojará un margen de utilidad que dividida entre
la inversión generará el retorno en la inversión el cual debe ser superior al
costo del dinero para asegurar la sustentabilidad de la organización.

20. Componentes del modelo

21. Componentes del modelo

22. Ejemplos innovación en el modelo de
negocio
• Un ejemplo que destaca para entender mejor este tipo de innovación es el
caso de la empresa Apple, Inc. de Cupertino, California. Como sabemos esta
compañía fue fundada por Steve Jobs y Steve Wozniak en 1976. Apple se
destacó desde su inicio por la innovación de sus familias de computadoras y
en sus famosos sistemas operativos. La introducción de la familia de
computadoras Macintosh en 1984, eventualmente posicionó
competitivamente a esta empresa en el mercado de las computadoras
personales.
• Sin embargo, fue a partir de la década pasada que Apple introduce otras
familias de productos como el IPod (2001), el iPhone (introducido en 2007 y
con 100 millones de celulares vendidos a la fecha) y el iPad (introducida en
abril de 2010 logra ventas de 15 millones de unidades a diciembre del mismo
año y ventas de 9,500 millones de dólares) y el último eslabón de estos
dispositivos, el iPad 2 (introducido en marzo de 2011).

23. Ejemplos
• Algunas preguntas que podemos plantearnos al buscar innovaciones en el
modelo de negocios son las siguientes…
• ¿Existen nuevos segmentos de mercado que no están siendo atendidos
adecuadamente?
• La contestación a esta pregunta le ha permitido a las empresas de
transporte aéreo atender al mercado que no utiliza este medio de transporte
con un modelo de negocio de bajo costo. La pionera fue Southwest Airlines
(que se convirtió en la primera línea en EUA con base en el número de
pasajeros domésticos transportados y más de 3,000 vuelos diarios) la cual ha
sido imitada en todo el mundo con empresas con modelos de negocio
similares.

24. Ejemplos
• ¿Cómo satisfacer las necesidades de los clientes con soluciones diferentes?
• Nestlé ha construido un nuevo modelo de negocio a partir de un sistema
propietario de cápsulas y máquinas que permiten preparar un expreso más
fácilmente con 16 diferentes tipos de café.
• ¿Podemos innovar en la forma como distribuimos nuestras soluciones a los
clientes?
• El caso de la compañía Dell que decidió comercializar directamente
permitiéndole ocupar actualmente el segundo lugar mundial como fabricante
de PC.

25. Ejemplos
• Una capacidad de innovar en el modelo de negocios más una habilidad para
la innovación tecnológica de productos y procesos de manufactura, nos
permitirá asegurar innovaciones en estas dos dimensiones lo que nos hará,
sin duda, una empresa líder en nuestra actividad.

26. Estándares
• Principales Estándares de Modelado de procesos de Negocios:
• Business Process Execution Language - BPEL
• Unified Modeling Language – UML
• Event-driven Process Chain – EPC
• Business Process Modeling Notation - BPMN

27. Estándares: BPMN en el Modelado del
Negocio.
• BPMN (Business Process Model and Notation) es un nuevo estándar de
modelado de procesos de negocio, en donde se presentan gráficamente las
diferentes etapas del proceso del mismo.
• La notación ha sido diseñada específicamente para coordinar la secuencia de
procesos y los mensajes que fluyen entre los diferentes procesos
participantes.
• El principal objetivo de BPMN es proporcionar una notación estándar que
sea fácilmente legible y entendible por parte de todos los involucrados e
interesados del negocio (stakeholders).
•

28. BPMN en el Modelado del Negocio.
• BPMN, está dirigido a gerentes, directores, dueños de empresas, ingenieros
de procesos, analistas de negocios, analistas de sistemas, administradores de
proyectos, responsables de calidad y todo aquel que necesita definir,
documentar y hacer más eficientes sus procesos de negocio con el estándar
más avanzado y aceptado a nivel internacional.
• El significado del usuario UML (El lenguaje de modelado unificado) toma un
perfil orientado a objetos en el modelado de aplicaciones, mientras que
BPMN toma un perfil orientado a procesos en el modelado de sistemas.
BPMN tiene un enfoque en procesos de negocio. UML se enfoca al diseño de
software y por lo tanto ambas notaciones son totalmente compatibles entre
si.

29. BPMN en el Modelado del Negocio.
• Las extensiones de UML para el modelado de negocio aportan elementos
muy importantes ya que proporcionan algunas otras vistas de la
arquitectura de negocio que son más difíciles de observar usando
únicamente BPMN.
• El modelado del negocio es la técnica por excelencia para alinear los
desarrollos con las metas y objetivos de las empresas e instituciones. Si se
realiza de tal forma en que el modelo puede consensuado entre los grupos
interesados, las posibilidades de éxito del proyecto aumentarán en forma
muy importante.
• El modelado de negocios, y más específicamente el modelado de procesos de
negocio, es la forma idónea para comunicarnos con los usuarios de todos los
niveles.

30. BPEL Lenguaje de Ejecución de Procesos
de Negocio
• Según la definición de la organización de estándares OASIS el “Business
Process Execution Language” (BPEL) es una forma de orquestar procesos de
negocio basada en estándares, compuesto por servicios.
• Como lenguaje de ejecución, WS-BPEL define como representar las
actividades en un proceso de negocio, junto al control de la lógica del flujo,
datos, correlación de mensajes, manejo de excepciones, y demás.
• Es un estándar diseñado para integrar una variedad de aplicaciones y
conseguir los objetivos de negocio independiente de las plataformas y
tecnologías con mayor escalabilidad y flexibilidad. BPEL o Lenguaje de
Ejecución de Procesos de Negocio puede definirse como un estándar basado
en XML diseñado para la “orquestación” de servicios Web.

31. BPEL Lenguaje de Ejecución de Procesos
de Negocio
Características
• Es la unión entre negocio y tecnología.
• Es un lenguaje XML que define como un proceso de negocios puede ser
ejecutado usando servicios Web.
• BPEL es un lenguaje de ejecución
• Estándar soportado por la mayoría de fabricantes Físicamente es un fichero
XML
• La ejecución de las funciones de negocio se gestiona a través de servicios
Web.

32. UML
• Es el lenguaje de modelado de sistemas de software más conocido y utilizado
en la actualidad; está respaldado por el OMG (Object Management Group).
• Es un lenguaje gráfico para visualizar, especificar, construir y documentar
un sistema. Prescribe un conjunto de notaciones y diagramas estándar para
modelar sistemas orientados a objetos, y describe la semántica esencial de lo
que estos diagramas y símbolos significan.
• El Lenguaje Unificado de Modelado (Unified Modeling Language) es un
estándar completo para describir sistemas de software. Facilita el
acercamiento entre el diseño de soluciones más favorables para la empresa y
el diseño detallado de sistemas de software.

33. UML
Características de UML
• Lo fundamental de una herramienta UML es la capacidad de diagramación,
y los diferentes tipos de diagramas que soporta la herramienta.
• Sus esquemas de apoyo de diseño, documentación, construcción e
implantación de sistema
• Su flexibilidad para admitir cambios no previstos durante el diseño o el
rediseño.
• UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y organizaciones del mundo real.

34. Diagramas UML
• Diagrama de casos de uso
• Diagrama de clases
• Diagrama de secuencia
• Diagrama de colaboración
• Diagrama de estado
• Diagrama de actividad
• Diagrama de componente
• Diagrama de despliegue

35. Diagramas
Técnicas habituales
• Casos de uso* de negocio: forma textual.
• Diagramas de actividades: forma diagramática.

36. Diagrama de caso de uso
• El diagrama de casos de uso representa la forma en como un Cliente (Actor)
opera con el sistema en desarrollo, además de la forma, tipo y orden en como
los elementos interactúan (operaciones o casos de uso).
• Un diagrama de casos de uso consta de los siguientes elementos:
 Actor.
 Casos de Uso.
 Relaciones de Uso, Herencia y Comunicación.

37. Caso de uso
• Un caso de uso es un conjunto de escenarios que tienen una meta de usuario
en común.
• Caso de Uso: Es una descripción de un proceso fina-fin, relativamente largo,
que incluye varias etapas o transacciones
• Es una manera específica de utilizar el sistema, es una historia que describe
un uso particular del sistema
• Es la imagen de una funcionalidad del sistema, desencadenada en respuesta
al estímulo de un actor o rol externo

38. Escenario
• Escenario: Es una secuencia de acciones e interacciones (pasos) entre los
usuarios (actores) y el sistema.
• Ejemplo:
• El usuario introduce su nombre de usuario y su contraseña. El sistema
verifica la validez del nombre de usuario y de la contraseña y permite al
usuario el acceso al sistema. El sistema muestra la pantalla principal del
sistema. El usuario selecciona la opción de añadir nuevo empleado. El
sistema muestra...

39. Actor, rol
• Un actor representa el rol jugado por una persona o cosa que actúa con el
sistema.
• Ejemplo:
• “Cliente, Administrador, Usuario no Registrado (Autenticado), Usuario
Registrado (Autenticado), Jefe de Compras, Jefe de Personal, Moderador,
Jefe de Departamento, Obrero de Planta, Supervisor...”
• NOTA: NO TODOS los interesados en el sistema (stakeholders) son actores,
sólo son actores aquellos que utilizarán el sistema

40. Características
• Actualmente, mucha gente considera que los casos de uso son de vital
importancia en los proyectos de software (Procesos Guiados por Casos de
Uso)
• Describen bajo la forma de acciones y reacciones el comportamiento de un
sistema desde el punto de vista de un usuario.
• Se puede considerar que hasta cierto punto, cada caso de uso es
independiente de los demás.
• Permiten definir los límites del sistema y las relaciones entre el sistema y su
entorno.

41. Descripción textual de los actores del
sistema

42. Descripción textual del caso de uso

43. Descripción textual del caso de uso

44. ¿Cómo se crea un modelo de caso de
uso?
• Actores
• Casos de uso
• Relaciones:
• Asociación
• Dependencia
• Generalización

45. ¿Cómo se crea un modelo de caso de
uso?
• Asociación: Es el tipo de relación más básica que indica la invocación desde un
actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con
una flecha simple.
• Dependencia o Instanciación: Es una forma muy particular de relación entre
clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha
relación se denota con una flecha punteada.
• Generalización: Este tipo de relación es uno de los más utilizados, cumple una
doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o
de Herencia(<<extends>>).
• Este tipo de relación esta orientado exclusivamente para casos de uso (y no para
actores).
 extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
 uses: Se recomienda utilizar cuando se tiene un conjunto de características que son
similares en más de un caso de uso y no se desea mantener copiada la descripción de la
característica.

46. Reglas
• Cada actor y caso de uso debe tener un nombre único.
• Los actores deben tener nombres y/o iconos representativos. Los nombres de
los actores deben representar roles
• El nombre de un caso de uso debe indicar acción y debe ser claro y conciso
• Forma General: Verbo (Infinitivo) + Predicado
• Evitar el cruce de líneas (En general, mantenga el diagrama ordenado)
• Evite tener demasiados casos de uso en el mismo diagrama (Regla 5 ± 2)

47. Reglas
• Evite el uso complejo de relaciones de extensión, especialización e inclusión
(No más de tres niveles)
• Narrar el flujo de eventos usando voz activa, en tiempo presente y desde la
perspectiva del actor
• Exprese cada paso del flujo usando la forma llamada y respuesta (reflejar el
hecho de que el actor ejecuta algo y el sistema responde a la solicitud del
actor)
• El caso de uso que se describe debe expresar un solo requisito funcional (No
trate de expresar más de un requisito funcional en el mismo caso de uso)

48. Ejemplo… errores???

49. Ejemplo: Convertir

50. Ejemplo: Convertir

51. Ejercicio
• Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema
debe controlar y/o aceptar:
• Registrar el número de ítemes ingresados.
• Imprimir un recibo cuando el usuario lo solicita:
 Describe lo depositado
 El valor de cada item
 Total
• El usuario/cliente presiona el botón de comienzo
• Existe un operador que desea saber lo siguiente:
 Cuantos ítemes han sido retornados en el día.
 Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
• El operador debe además poder cambiar:
 Información asociada a ítemes.
 Dar una alarma en el caso de que:
 Item se atora.
 No hay más papel.

52. Modelado del Negocio (Diagrama de
Actividades
• ¿ Qué é son los diagramas de actividad?
• Es una notación que forma parte de UML y que se utiliza principalmente
para modelar procesos de negocio, especificando:
 La secuencia de actividades que componen los procesos de negocio.
 Los actores que realizan las actividades (opcional).
 La información que fluye de unas actividades a otras (opcional).
• Dentro del proceso de ingeniería de requisitos, se utilizarán para modelar los
procesos de negocio, tanto actuales como a implantar, de la organización
para la que se va a desarrollar el sistema software.
• A partir del modelo del negocio al que el sistema software debe dar soporte,
se plantean los objetivos y requisitos del sistema a desarrollar.

53. Actividades
• Una actividad representa un paso dentro de proceso de negocio.
• Su nombre, que debe ser siempre una forma verbal, debe ser representativo
y coherente dentro del proceso de negocio.
• Si una actividad es compleja, puede ser necesario mostrar su descomposición
en actividades más simples en otro diagrama.
• En cada diagrama de actividades, las actividades deben tener un nivel de
abstracción similar.
• Actividades iniciales y finales:
 La actividad inicial, que debe ser única, indica dónde comienza el proceso de
negocio.
 Una actividad final, de las que puede haber varias o ninguna (proceso sin fin),
indica dónde puede terminar el proceso de negocio.

54. Transiciones
• Indican la secuencia de actividades que componen el proceso de negocio.
• Cuando una actividad termina de realizarse se produce la transición hacia la
siguiente actividad.
• Transiciones condicionales
• Indican que la siguiente actividad a realizar depende de cierta condición.
• Como mínimo y como máximo, sólo puede haber una opción válida al evaluar
la condición.
• El símbolo de condición se puede usar también para unir varios caminos
condicionales (opcional).

55. Paralelismo
• A veces, algunos pasos de un proceso de negocio se realizan
simultáneamente (en paralelo) o sin un orden definido.
• Para indicar que comienzan varias actividades a la vez se usa un
símbolo de comienzo de paralelismo (fork), al que llega una
transición y del que salen varias (al menos dos).
• Para indicar que todas las actividades que se hacían en paralelo
han terminado se usa un símbolo de fin de paralelismo (join), al
que llegan varias transiciones (al menos dos) y del que sale una
sola transición.
• La transición de salida del join sólo se realiza cuando han
terminado todas las actividades que se realizaban en paralelo.

56. Calles
• La división en calles permite asociar actividades con aquellos actores que las
realizan.
• Cada calle corresponde a un actor del proceso de negocio.

57. Ejemplo

58. Ejemplo:
• Se debe realizar un diagrama de actividad que describa la realización de un
pedido telefónico de un cliente. Se debe considerar:
El cliente solicita una producto y es atendido por un vendedor de la empresa.
• Si el cliente es nuevo se le abre una ficha de cliente.
• Para el cliente y el producto solicitado se realizan simultáneamente las
siguientes acciones:
 Consultar el stock. Si no existen existencias del artículo se informa al cliente y se termina
el proceso.
 Consultar el riesgo del cliente. Si el crédito que tiene el cliente supera el valor del artículo
se informa al cliente y se termina el proceso.
• Una vez hechas estas comprobaciones, si son correctas, se informa del precio al
cliente que lo puede aceptar o rechazar. Si lo rechaza se termina y si lo acepta el
cliente realiza el pedido y el vendedor lo regista y se termina el proceso.
• Una vez realizado el diagrama crear un nuevo diagrama con dos carriles que
separen las actividades de los actores: cliente y vendedor.

59. Ejercicio
• Se debe realizar un diagrama de actividad que refleje el proceso de registro en
una Web. Se debe considerar:
• El usuario debe introducir un nombre de usuario válido. Los criterios de validez
los pone el sitio.
• El usuario debe introducir una contraseña válida. La política de contraseñas la
pone el sitio.
• El usuario debe repetir la contraseña. Esta debe coincidir con la introducida con
anterioridad.
• El usuario debe introducir el resto de los datos.
• Si se han introducido correctamente los datos se solicita confirmación al usuario.
• El usuario confirma y se le avisa de que el registro ha sido correcto.
• Una vez hecho el diagrama de actividad se debe realizar una nueva versión con
carriles que contemple los actores usuario y sitio.

60. Ejercicio
• Se debe realizar un diagrama de actividad que describa el proceso de
validación de un usuario en un cajero automático. Se debe considerar:
El cliente debe introducir la tarjeta, el PIN y la operación que ha de realizar.
• Se comprueba si el PIN es correcto para esta tarjeta.
• Se comprueba si la tarjeta es válida.
• Si resultan válidas las dos operaciones anteriores se realiza la operación y se
informa al usuario.
• Una vez realizado generar otra versión del diagrama que contemple las
acciones de cada actor, haciendo carriles para el cliente y el banco.

61. Bibliografía
• Montilva, J. Besembel, I., Pérez, M. y Losavio, F. Sistemas de Información e
Ingeniería de Software: Temas Selectos. Editorial: Centro de Estudios en
Informática. Mérida, Venezuela, 2005. (ISBN: 980-12-0585-7).
• Montilva, J. and Barrios, J. BMM: A Business Modeling Method for
Information Systems Development. CLEI Electronic Journal, Vol. 7, No. 2,
December 2004.
• Barrios, J. And Montilva, J. Business Modelling through Roadmaps.
Proceedings of the 6th International Conference on Enterprise Information
Systems (ICEIS’2004). Porto, Portugal, April, 2004.
• Barrios, J. And Montilva, J. A Methodological Framework for Business
Modelling. Proceedings of the 5th International Conference on Enterprise
Information Systems (ICEIS’2003). Angers, France, 2003.