Ads Sesion 02

Análisis y Diseño Análisis y Diseño de Sistemasde Sistemas

Sesión # 02Sesión # 02Fecha:Fecha:

27/04/23Análisis y Diseño de Sistemas Orientado a Objetos 2

27/04/23Análisis y Diseño de Sistemas Orientados a Objetos 3

ContenidoContenido1.1. Modelo de NegocioModelo de Negocio2.2. IntroducciónIntroducción3.3. VistasVistas4.4. Modelo de Casos de Uso del NegocioModelo de Casos de Uso del Negocio

1.1. EstructuraEstructura2.2. Identificación de Objetivos, Actores y Casos de Uso del Identificación de Objetivos, Actores y Casos de Uso del

NegocioNegocio3.3. Diagrama de Casos de Uso del NegocioDiagrama de Casos de Uso del Negocio

ObjetivosObjetivos

27/04/23CURSO: Análisis y Diseño de Sistemas 4

• Comprender la estructura y la dinámica de la organización objetivo.

• Comprender los problemas actuales de la organización objetivo e identificar

el campo de acción incluido en donde hay un potencial incluido de

crecimiento y mejoras.

• Evaluar el impacto del cambio en la organización objetivo.

• Asegurar que los clientes y usuarios finales, desarrolladores y otros roles

tengan un rendimiento común de la organización objetivo.

• Obtener de forma preliminar, los requerimientos del sistema que necesita la

organización objetivo.

27/04/235

1. Modelo de Negocios1. Modelo de Negocios

Análisis y Diseño de Sistemas Orientado a Objetos

Roles y ResponsabilidadesRoles y Responsabilidades


Actividades del Modelo de Actividades del Modelo de NegocioNegocio


Vistas del Modelo de NegocioVistas del Modelo de Negocio


Vista Externa del negocio Vista Interna del negocio

Identificación de Artefactos Identificación de Artefactos • Bussines Goal

• Busines Actor

• Bussines Use Case


Bussines Goal (BG)Bussines Goal (BG)• Un Bussines Goal es un requisito que el negocio debe satisfacer. • El objetivo de negocios debe ser:

Alcanzable, que sea posible lograrlo (con recursos y capacidades a disposición).

Claro sobre qué, dónde, cuándo y cómo va a cambiar la situación .Mesurable, que sea posible cuantificar los fines y beneficios.Realista, que sea posible obtener el nivel de cambio reflejado.Sensible al tiempo, estableciendo el periodo de tiempo en el que

debe concretarse.


Bussines Actor (BA)Bussines Actor (BA)


• Un Business Actor, representa un ROL jugado por alguien o algo externo al negocio y que interactúa o se relaciona con el.

• Un BA se beneficia o afecta por los resultados del proceso.

Bussines Use CaseBussines Use Case• Describe un proceso de negocio desde un punto de vista externo

que percibe algún tipo de valor.• Ubicación fuera de las fronteras del negocio.• No siempre se identifica con el nombre de un cargo de la

Organización• Representar el nombre con roles de ejecución, más no áreas o

departamentos de la Organización.• Son roles (humanos, software o hardware), no personas con

nombres propios.• Asociarse con al menos un CUN• De no participar en algún proceso debe ser eliminado del modelo


Identificar Bussines Use Case Identificar Bussines Use Case (BUC)(BUC)


• Un BUC identifica un proceso específico del 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 un valor.

• Categorías: básicas, estratégicas y de apoyo

Bussines Use Case DiagramBussines Use Case Diagram


• Se basa en los principios del diagrama de casos de uso de UML.• Muestra los procesos del Negocio que son usados por los roles

del negocio.• Solo se tiene en cuenta “¿Quién se beneficia? / ¿Qué proceso?”

QUIEN (actor del negocio identificado) QUE(caso de uso del negocio identificado)

• Relaciones entre ellos(asociaciones)

Ejercicio # 1Ejercicio # 1• En el Área de Abastecimientos de una empresa, el

Actor de negocio, externo al proceso es el Proveedor. Este actor interviene en los procesos de Compra de Productos (por parte de la empresa), Devolución de Productos (por parte de la empresa) y Recepción de Productos (comprados por la empresa)


SoluciónSolución• Bussines Actor:• Bussines Use Case:• Bussines Use Case Diagram


27/04/2317

ConclusionesConclusionesNO constituye un diagrama de flujo de datos, ni menos NO constituye un diagrama de flujo de datos, ni menos presenta la secuencialidad entre los procesospresenta la secuencialidad entre los procesos

Análisis y Diseño Orientado a Objetos

27/04/23Análisis y Diseño de Sistemas orientado a Objetos 18

BibliografíaBibliografía- Rumbaugh J. El Proceso Unificado de Desarrollo de Software. Rumbaugh J. El Proceso Unificado de Desarrollo de Software.

PEARSON Educación SAPEARSON Educación SA- PMI Fundamentos para la Dirección de Proyectos (Guía del PMI Fundamentos para la Dirección de Proyectos (Guía del

PMBOK)PMBOK)

Ads Sesion 02

Documents

Transcript of Ads Sesion 02