02 modelo delnegocio
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

02 modelo delnegocio

on

  • 1,563 views

 

Statistics

Views

Total Views
1,563
Views on SlideShare
667
Embed Views
896

Actions

Likes
0
Downloads
57
Comments
0

5 Embeds 896

http://omarcelismendoza.blogspot.com 849
http://omarcelismendoza.blogspot.mx 19
http://omarcelismendoza.blogspot.com.ar 17
http://omarcelismendoza.blogspot.com.es 7
http://omarcelismendoza.blogspot.co.uk 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • {}

02 modelo delnegocio Presentation Transcript

  • 1. Desarrollo de software orientado a objetos Unidad 2: Modelo del Negocio
  • 2. Agenda  Introducción  Modelo de Casos de Uso del negocio  Modelo de Objetos del Negocio.  Refinamiento del Modelo de Negocio
  • 3. Introducción
  • 4. ¿Por qué es necesario modelar los procesos de la empresa?  Para identificar con facilidad donde están sus problemas u oportunidades de crecimiento y mejora.  Porque desde la perspectiva de los sistemas no es posible automatizar procesos que no estén claramente definidos.
  • 5. Introducción La empresa y sus procesos ¿Cuáles son y a quiénes están dirigidos? ¿Cuáles son sus resultados? ¿Cuáles son las tareas que se deben llevar a cabo?
  • 6. Introducción Objetivos:  Comprender la estructura y la dinámica de una organización en donde el sistema a desarrollar va a ser instalado (objeto de estudio u organización destino).  Comprender los problemas actuales de la organización destino e identificar su potencial de crecimiento y mejoras. ..........
  • 7. Introducción ......  Asegurar que los clientes, usuarios finales y desarrolladores tengan un entendimiento común del objeto de estudio.  Derivar los requerimientos del sistema necesarios para dar soporte a la organización destino.
  • 8. Modelo de casos de uso de negocio
  • 9. Modelo de casos de uso del negocio  El modelo describe el negocio en términos de casos de uso de negocio “business use cases” que se corresponden con lo que comúnmente se conoce como "procesos".
  • 10. Modelo de casos de uso del negocio  Forman parte del modelo:  La vista externa  Actores y casos de uso de negocio (Business Actors y Business Use Cases).  Diagramas de caso de uso del negocio.  La vista interna  Objetos de negocio  Diagramas de actividad (Workflow).
  • 11. Elementos del modelo del negocio  Tareas de la vista externa  Encontrar y describir actores del negocio.  Encontrar y describir casos de uso del negocio.  Efectuar diagramas de casos de uso del negocio.  Tareas de la vista interna  Encontrar y describir los objetos de negocio que participan realizando los procesos.  Descomponer los procesos de negocio en flujos de trabajo (Workflows) para describirlos a detalle.
  • 12. Encontrar actores del negocio  Un “business actor” (actor del negocio) representa un rol que alguien o algo en el entorno del sistema puede realizar en relación con el negocio.
  • 13. Encontrar actores del negocio  Existen dos grandes categorías de BA:  El Cliente (Customer)  La “razón de ser” del negocio.  Se benefician o afectan por los resultados del proceso.  El Socio o decisor (Stakeholder).  Son los dueños del proceso.  Los resultados del proceso le sirven para tomar decisiones.  No participan de la parte operativa.
  • 14. Encontrar actores del negocio  Categorías donde los clientes pueden ser hallados:  Clientes (los beneficiarios o afectados por el proceso).  Proveedores.  Autoridades (entidades legales, reguladoras, etc.).  Sistemas de información localizados fuera del negocio.
  • 15. Encontrar actores del negocio  Categorías donde los stakeholders pueden ser hallados:  Sucursales.  Dueños, inversionistas, gerentes.  Se debe modelar a un miembro del directorio si es parte activa del negocio.
  • 16. Encontrar actores del negocio  Si los procesos que van a ser modelados son parte de una gran compañía, se puede encontrar actores de negocio en:  Otras partes de la compañía.  Roles individuales gerenciales en otros departamentos.  Subsistemas que reciben o transmiten información.
  • 17. Encontrar actores del negocio  Se debe asignar un nombre a cada actor del negocio de acuerdo al rol desempeñado en el negocio.  Para cada actor del negocio se debe especificar una breve descripción que incluya sus responsabilidades y la razón de su interacción con el negocio.
  • 18. Generalización de actores del negocio  Varios actores de negocio pueden desempeñar el mismo rol para un caso de uso de negocio particular.  Ejemplo: Tanto el viajero de negocios como el turista pueden viajar y registrarse en el counter del aeropuerto (check-in). El rol compartido pasajero se modela como un business actor.
  • 19. Generalización de actores del negocio Pasajero Viajero de negocios Turista
  • 20. Encontrar casos de uso del negocio  Un “business use case” es un proceso de negocio que produce un resultado de valor medible y esperado por un actor (o actores) en particular.  Representa la secuencia de actividades desarrolladas para lograr ese valor.
  • 21. ¿Cómo encontrar casos de uso del negocio?  Identificar las necesidades puntuales del business actor y que conjunto de actividades se realizan para satisfacerlas.  Identificar los resultados y entregables que tiene la empresa y a partir de ellos a los procesos que los realizaron.  Reconocer los procesos tipo del giro del negocio, por comparación con el de otras empresas o a partir del estudio de la cadena de valor.
  • 22. Procesos “tipo”  Los procesos “tipo” de una empresa se pueden reconocer en una de las siguientes categorías.  Procesos primarios, comerciales o de valor.  Procesos secundarios de apoyo y administrativos.
  • 23. Procesos primarios  En primer lugar están las actividades comerciales importantes o vitales del negocio que usualmente se llaman “business processes”.  Son los procesos dirigidos al cliente. Vender Productos
  • 24. Procesos secundarios  En segundo lugar existen las actividades de soporte o apoyo, que no son importantes desde el punto de vista comercial pero que se deben efectuar de todos modos para hacer que el negocio camine. En esta categoría está: la administración del sistema, la limpieza, la seguridad, etc. Realizar Inventario
  • 25. Procesos secundarios  Dentro de está categoría también está el trabajo administrativo. Estos casos de uso muestran el tipo de trabajo que afecta el cómo los otros procesos son llevados a cabo, Realizar Planilla
  • 26. Guías para encontrar casos de uso del negocio ¿Por donde comenzar?  Es recomendable comenzar con el más importante actor del negocio: el cliente.  ¿Cuáles son los principales servicios que el cliente obtiene del negocio?  ¿Cuál es el ciclo de vida de un cliente? Un buen consejo es estudiar el ciclo de vida del cliente (y los objetivos parciales e intermedios que va logrando en el tiempo)
  • 27. Guías para encontrar casos de uso del negocio  ¿Cuáles son las características principales de soporte a los negocios y cuando se dan? En estos grupos de características se pueden hallar casos de uso del negocio.  ¿Cuáles son los procesos que ayudan a tomar decisiones estratégicas?
  • 28. Guías para encontrar casos de uso del negocio  Para completar su definición se debe:  Desarrollar y abastecer de información acerca de nuevas tendencias del negocio a los dueños e inversionistas.  Identificar y establecer metas presupuestales a mediano y largo plazo.  Coordinar y asignar prioridad entre los casos de uso del negocio.  Crear nuevos procesos en el negocio.  Supervisar los procesos del negocio
  • 29. Diagramas de Caso de Uso del Negocio  Muestran la agrupación de procesos en paquetes (grandes procesos) y la descomposición de los mismos en casos de uso de negocio  Muestran la interacción de actores de y casos de uso de negocio.  Muestran el contexto del negocio.
  • 30. Consideraciones en Diagramas de Caso de Uso del Negocio  ¿Los Business Use Cases están siempre relacionados con algún Business Actor?  Cada caso de uso del negocio primario debe tener una relación de comunicación o vínculo con un actor de negocios.  Esta regla refuerza el objetivo de que los negocios se hacen y construyen para satisfacer los requerimientos de sus usuarios.
  • 31. Consideraciones en Diagramas de Caso de Uso del Negocio  ......  Si un modelo de casos de uso tiene procesos que no son requeridos por nadie, puede estar reflejando que algo malo está ocurriendo con el modelo. Pero, existen excepciones.....
  • 32. Diagramas de Caso de Uso del Negocio .....  Los casos de uso administrativos y de soporte no necesariamente están conectados con un business actor, no obstante, dependen de algún contacto externo.  Los casos de uso abstractos son los únicos que no necesitan un business actor porque nunca son iniciados por ellos.
  • 33. Diagrama de Casos de Uso (primer nivel o nivel 0) Gestión de Compras Gestión de Ventas Gestión de Cobranza
  • 34. Diagrama de Casos de Uso (Gestión de Ventas) Contactar Clientes Cliente Realizar Pedido Realizar Venta Gestión de Ventas Gte. Marketing
  • 35. Características de un buen modelo de caso de uso del negocio  Los casos de uso conforman el negocio que describen.  Todos los casos de uso deben ser encontrados. Todos juntos realizan las actividades propias del negocio.  Toda actividad del negocio debe estar incluida en un caso de uso por lo menos.
  • 36. Características ....(cont.)  Debe haber un balance entre el número de casos de uso del negocio (BUC) y su tamaño.  Menos BUC hacen que el modelo sea mas fácil de comprender.  Casos de Uso muy largos y complejos son muy difíciles de digerir.  Hay que asegurar que los casos de uso describan un workflow completo que produzca algo de valor para el cliente.
  • 37. Modelo de objetos de negocio
  • 38. Modelo de objetos del negocio  Un modelo de objetos de negocio define los BUC desde el punto de vista del trabajador (business worker) o cliente interno.  El modelo define como la gente (que trabaja en el negocio) y las cosas (clases y objetos del negocio) que ellos utilizan y administran se relacionan para producir los resultados esperados.
  • 39. Modelo de objetos del negocio  Pone énfasis en los roles asumidos en el área de negocios, con sus actividades y responsabilidades.  Tanto los roles (business workers) como los objetos (business entities) juntos deben ser capaces de llevar a cabo todos los BUC.
  • 40. Modelo de objetos del negocio  El modelo de objetos del negocio describe los conceptos que permiten la realización de los business use case.  Describe “cómo” interactúan los objetos al interior de la empresa para concretar uno o varios proceso.
  • 41. Modelo de objetos del negocio  Objetivos:  Identificar los niveles de organización (unidades del negocio).  Identificar a los roles significativos al interior de las unidades de negocio.  Identificar objetos del negocio o recursos materiales relevantes.
  • 42. Elementos clave  Business workers (BW) muestra el conjunto de responsabilidades que una persona (rol) asume en la empresa.    Business entities (BE) Representa los entregables, recursos y eventos que son usados o producidos.  Organization Units (OU) agrupa a los businees workers y business entities y otras organization units que estan administrativamente relacionadas.
  • 43. Identificando business workers Un business worker representa un rol o un conjunto de roles en el negocio. Un business worker trabaja en una unidad organizacional, interactúa con otros business workers y manipula entidades a través de la realización de los casos de uso de negocio.
  • 44. Identificando business workers Ejemplo: Vendedor, Encargado de almacén, Cajero.
  • 45. Consideraciones (checkpoints) sobre BW  El nombre y la descripción deben ser claros y comprensibles.  Cada BW debe tener documentada una asociación con otro BW si se comunican entre sí.  Cada BW debe participar en un BUC por lo menos.  Cada relación entre BW y otros BW o BE debe ser usada en el workflow de algún BUC.  Cada operación de un BW debe ser usada en el workflow de algún BUC.
  • 46. Identificando las entidades del negocio  Las BE representan “cosas” que son manipuladas o usadas por los BW cuando ejecutan un BUC.  Comúnmente representa un documento o una parte esencial de un producto.  Algunas veces representa cosas no tangibles como el conocimiento importante acerca de un mercado o cliente.  Ejemplos: En un restaurante: el menú, las bebidas, etc. En el aeropuerto: el boleto, el boarding pass, etc.
  • 47. Identificando las entidades del negocio  Ejemplo: Producto, factura, guía de remisión, pago de crédito.
  • 48. Identificando las entidades del negocio En resumen:  Son cosas que son manipuladas o manejadas por el business worker. (tangibles o intangibles).  Son recursos de la empresa  Contiene atributos y operaciones.  Se puede especificar herencia.  Representa formatos, datos (persistentes y no persistentes), reportes, etc.
  • 49. Consideraciones (checkpoints) sobre BE  El nombre y la descripción deben ser claros y comprensibles.  Cada BE es usada en al menos un BUC.  Cada relación entre BE y otras BE o BW es usada en algún caso de uso por lo menos.  Todas las BE tienen un propietario que puede ser un BW o BA.
  • 50. Identificando las unidades de la organización  Usualmente un negocio es estructurado en departamentos, secciones y áreas.  Una unidad de la organización divide el negocio en partes más pequeñas.  Dentro de él se encuentran business workers, entidades del negocio y otras unidades de la organización
  • 51. Identificando las unidades de la organización Ejemplo: Unidad de Ventas, Unidad de Contabilidad, etc.
  • 52. Refinamiento del modelo de negocio
  • 53. Refinamiento del modelo de negocios.  El propósito de esta actividad es:  Detallar la definición (workflow) de cada business use case en cada uno de sus escenarios.  Verificar que los BUC reflejen correctamente como el negocio se hace.
  • 54. Diagrama de actividades (DA)  Un diagrama de actividades (AD) detalla el flujo de trabajo (workflow) de un BUC.  Un BUC consiste de una secuencia de actividades que juntas producen algo de valor para un business actor.  Un workflow usualmente consiste de un flujo básico y uno o muchos flujos alternativos.
  • 55. Elementos de un DA  Un diagrama de actividades tiene los siguientes elementos: Estados de Actividad:  Representan el desarrollo de una actividad o paso dentro de un workflow.
  • 56. Elementos de un DA Estado Inicial  Representa el inicio de un workflow.  Existe un único estado inicial.
  • 57. Elementos de un DA Estado Final  Representa el fin de un flujo de actividades en el workflow.  Puede haber más de un estado final.
  • 58. Elementos de un DA Estado transitorio  Representa tiempos de espera en un proceso.
  • 59. Elementos de un DA Transiciones  Muestra que actividad sigue a la otra. Se puede definir como una transición completa (porque ocurre cuando se termina la actividad precedente y no necesita de un evento que la propicie).
  • 60. Elementos de un DA Decisiones  Para las cuales se definen un conjunto de condiciones de restricción. Estas condiciones controlan que transiciones (de un conjunto de posibles transiciones) continúan cuando la actividad se ha completado. También se puede usar la decisión cuando se quieren juntar hilos de flujos y combinarlos de nuevo.
  • 61. Elementos de un DA Barras de Sincronización  Son usadas para mostrar subflujos paralelos. Permiten mostrar caminos concurrentes dentro de un workflow.
  • 62. Características especiales  Las posibles complejidades de los workflows pueden ser tratadas a través de diferentes características como son:  Actividades anidadas  Swimlanes (calles).  Uso de objetos.
  • 63. Actividades anidadas  Una actividad puede referencia a otro diagrama de actividad que muestra la estructura interna de un estado de la actividad.  Cuando el diagrama interno es muy complejo se puede documentar que la actividad hace referencia a otro workflow (crear otro nivel de descomposición).
  • 64. Actividades anidadas Actividad 4  Actividad con enlace a otro workflow do/ Subproceso A Subproceso A Paso 1 Paso 2
  • 65. Swimlanes  Un diagrama de actividad puede estar particionado en swimlanes usando líneas rectas verticales. Cada swimlane representa una parte del workflow cuya responsabilidad esta a cargo de una parte de la organización.
  • 66. Swimlanes  Eventualmente un swimlane puede ser implementado por una unidad organizacional o por un conjunto de clases en el modelo de objetos del negocio.  El orden de presentación de los swinlanes no tiene significado semántico.
  • 67. Uso de objetos  En este contexto los flujos de objetos son usados para mostrar como las entidades de negocio son creadas y usadas en un workflow.  Los flujos de objetos permiten mostrar inputs y outputs desde actividades.
  • 68. Uso de objetos Consideraciones:  Un objeto puede ser el output de una actividad y el input de muchas otras.  El flujo que los enlaza a una actividad es una clase de flujo de control.  El mismo objeto puede ser manipuladao por una serie de actividades que pueden cambiar su estado, por lo tanto puede ser mostrado muchas veces (denotando entre corchetes su estado).
  • 69. Uso de Objetos
  • 70. Uso de objetos  Los objetos y sus flujos pueden ser comparados con los data flows.  A diferencia de los data flows tradicionales, los objetos se muestran en un punto definido dentro del grafo del diagrama de actividades.
  • 71. Conclusiones  El análisis de los procesos de negocio es diferente al de los procesos del sistema. Involucra actividades automáticas y manuales necesarias para lograr los resultados requeridos por la empresa.  El modelo es muy útil para documentar, identificar problemas en los procesos, y posteriormente refinarlos.  No se puede realizar o implementar un buen sistema si los procesos de negocios no están preparados para la automatización.  Un sistema no resuelve problemas organizacionales