Formato - Clase - Introducción A Requerimientos y Modelo de Negocios - Clase - PRO103 - 3603 - N5 - 9

INTRODUCCIÓN DE REQUERIMIENTOS
Y MODELOS DE NEGOCIO
Clase N° 9
21 – Abril - 2021
CONDICIONES FAVORABLES PARA LA CLASE
Mantén todos tus

sentidos activos
Práctica la puntualidad
Mantén tus dispositivos

electrónicos en silencio
Respeta el turno de
participación
PRESENTACIÓN DE LA CLASE
Aprendizaje Esperado: Caracterizan objetivo del modelado de los procesos de negocio, considerando
el desarrollo ágil de soluciones a las necesidades de los distintos tipos de
organizaciones.
Criterios de Evaluación: Preguntas y participación en clases.
1. DFD (diagramas de flujo de datos).

Contenidos: 2. Diagramas para el modelado de los procesos de negocio.
3. Tipos arquitectura negocio dentro de las organizaciones (Sociales, Empresa y
Gobierno).
4. Procesos de negocio y gobernabilidad para el desarrollo ágil
MOMENTO PARA RECORDAR
Metodologías Agiles
Roles Scrum
UML, Franca y
Uso
Metadato,
Diagramas, Vistas,
modelar
Casos de uso, clase,

Secuencia y otros
MOMENTO PARA CONOCER
CASOS DE USO DE SISTEMAS
Esta semana que paso hablábamos de los tipos de

relaciones en diagramas de casos de uso que nos
ofrece UML, hoy nos vamos a centrar en las
especificaciones detalladas de casos de uso o
representaciones textuales, que aunque UML no las
especifica directamente, se utilizan de forma habitual.
Partimos de la base de que los casos de uso son

requisitos y más aún podríamos decir que son requisitos
funcionales que nos indican que va a hacer el sistema.
Muchas veces solemos caer en el error de vincular el

modelo de casos de uso exclusivamente al diagrama, es
decir a la representación gráfica (al dibujo) pues bien, los
casos de uso son sobre todo documentos de texto.
CASOS DE USO
Con todo esto podemos decir que la especificación de casos de
uso se centra en la escritura en vez del dibujo.
Los casos de uso se escriben con formatos diferentes

dependiendo del nivel de detalle que queramos alcanzar.
Los grados de formalidad con los que podemos escribir un caso

de uso son:
1. Breve: Descripción en unas pocas líneas.

2. Informal: Varios párrafos en un estilo informal que cubren
varios escenarios, entendiendo por escenario a una instancia
de un caso de uso, una historia particular de uso del sistema.
3. Completo: El más elaborado, se trata de una descripción
detallada con una plantilla.
CASOS DE USO
Nos vamos a centrar en estos
últimos, los casos de uso
completos muestran más
detalles y están
estructurados.
CASOS DE USO
También podríamos añadir otros

aspectos como:
DIAGRAMA DE CASO DE USO OPENBIKES
ARRIENDO DE BICICLETAS CAMBIO
CLAVE
Suscripción LOGIN Administrador

VALIDACION
USUARIO
CLIENTE
Ubicar Reservar
Bici Mantención
Usuarios
CLIENTE
Desloqueo
Candado Cobro Cartola de
Suplemento uso servicio
En tránsito Usuarios operativos

Anclar BIce
Pago
Suplemento y Otras
SISTEMA OPENBIKES mensualidad Funciones
Servicio Técnico
CASOS DE USO DE NEGOCIO
Una vez definido el emprendimiento o proyecto que se
abordará, se puede empezar a desarrollar la Modelación
del Negocio de la empresa.
El primer paso es la determinación de los Actores del

Negocio que se hace por medio de la identificación de los
procesos de la institución o empresa, cada uno de los
procesos identificados puede ser un Casos de Uso del
Negocio.
Para desarrollar el Diagrama de Casos de Uso del Negocio

se debe estudiar los estereotipos de Casos de Uso del
Negocio y el de Actor del Negocio.
Se conoce con el nombre de estereotipo a

la percepción exagerada y con pocos detalles, simplificada,
que se tiene sobre una persona o grupo de personas que
comparten ciertas características, cualidades y habilidades,
que busca «justificar o racionalizar una cierta conducta en
relación a determinada categoría social».
Regularmente los estereotipos son basados en prejuicios que

la sociedad establece conforme su ideología de «modelo a
seguir» de conducta o características físicas, estos van
cambiando conforme el paso del tiempo.
Estos dos estereotipos (Casos de Uso del Negocio y el

de Actor del Negocio.) son suficientes para iniciar la
creación del Diagrama de Casos de Uso del Negocio.
El Modelo de Caso de Uso del Negocio implicará la

determinación de los Actores y Casos de Uso del
Negocio, como se ha dicho anteriormente. Con ésta
actividad se pretende:
 Identificar los procesos en el negocio

 Definir las fronteras del negocio que van a
modelarse
 Definir quién y qué interactuarán con el negocio
 Crear diagramas del modelo de casos de uso del
negocio
Un candidato a Actor del Negocio es cualquier individuo,

grupo, organización o máquina que interactúa con el
negocio. Por tanto, éstos pueden ser:
• Clientes o potenciales clientes

• Socios
• Proveedores
• Autoridades
• Propietarios
• Sistemas de información externos al negocio
• Otras parte de la organización, si la organización es
grande
El término Actor del Negocio significa el rol que algo o
alguien juega cuando interactúa con el negocio.
De acuerdo con esta idea un Actor del Negocio

representa un tipo particular de usuario del negocio
más que un usuario físico, ya que varios usuarios físicos
pueden realizar el mismo papel en relación al negocio,
o sea, ser instancias de un mismo actor. Sin embargo,
un mismo usuario puede actuar como diferentes
actores.
El nombre de un Actor del Negocio debe hacerse de

modo que exprese su rol dentro del negocio y cada
Actor del Negocio debe definirse brevemente con su
responsabilidad y por qué interactúa con el negocio.
Los Actores del Negocio interactúan con el negocio enviando y

recibiendo mensajes, y para conocer el papel del actor se debe
precisar en qué procesos se involucra el actor., esto se muestra
por la llamada asociación de comunicación, entre el Actor del
Negocio y el Caso de Uso del Negocio que representa al
proceso.
Un Caso de Uso del Negocio define qué debe ocurrir en el

negocio cuando este se realiza, describe el comportamiento de
una sucesión de acciones que produce un resultado de valor
para un Actor particular del negocio.
Es decir, un Caso de Uso del Negocio describe una secuencia

de acciones realizadas en el negocio que produce un resultado
de valor observable para un actor individual del negocio..
Con estos tres estereotipos se puede desarrollar un

Modelo de Objeto del Negocio, donde este modelo
identifica todos los “roles” y “cosas” en el negocio, los
cuales son representados como clases en la Vista Lógica.
El Modelo de Objeto es creado a través de los Diagramas

de Actividad que describen los Casos de Uso del Negocio
con los objetos o documentos incluidos.
Generalmente el primer flujo que inicia el Diagrama de

Actividad corresponde a un Actor del Negocio, las restantes
pertenecen a un Trabajador del Negocio.
BUSINESS PROCESS MANAGEMENT “BPM”
Actualmente hay mucha confusión en el mercado respecto al

término BPM, Business Process Management (Gestión por
Procesos).
Se piensa que adquiriendo tecnología para la automatización

de procesos de negocio se pueden resolver los problemas
empresariales y que la mejora en eficiencia vendrá como
resultado inmediato. Nada más lejos de la realidad.
La tecnología adquirida es sólo un conjunto de piezas de

software que no incluyen técnicas, ni metodologías de
implementación, ni conocimientos de una gestión transversal
de los procesos de negocio de principio a fin a lo largo de
todas las unidades funcionales de la empresa, ni el
compromiso de liderazgo de los directivos, entre otros.
Dado que en dichas implementaciones no se ha

gestionado el cambio organizacional, ni los
impactos sobre las personas implicadas, ni se ha
adquirido la metodología adecuada para la
gestión empresarial por procesos, no se ha creado
una cultura BPM y las empresas se encuentran
totalmente perdidas para dar un paso más allá,
cuestionando la utilidad de las tecnologías BPM y
el retorno de la inversión.
BPM, que va más allá del aspecto tecnológico, es un

sistema de gestión enfocado a perseguir la mejora
continua del funcionamiento de las actividades
empresariales mediante la identificación y selección de
procesos y la descripción, documentación y mejora de
los mismos, partiendo del despliegue de la estrategia de
la organización, asegurando la misión empresarial y
alineada a la visión de la empresa.
El BPM debe estar alineado con la estrategia, con la

gestión de recursos humanos, con la gestión financiera,
con la gestión de la información, con la gestión de la
calidad y con las disciplinas tradicionales de gestión.
La Gestión por Procesos es impulsada y hecha realidad

por un conjunto de tecnologías totalmente maduras
que permiten alcanzar unos resultados excelentes.
En un entorno tan competitivo como el actual, lleno de

turbulencias e incertidumbre, las empresas son
conscientes de que su nivel de eficiencia está en función
de sus procesos y de su agilidad de respuesta tanto a
situaciones inesperadas como previsibles.
La solución conlleva reaccionar ante la ineficiencia

derivada de organizaciones departamentales, con sus
nichos de poder y su preocupación por conseguir
objetivos individuales.
Si potenciamos el concepto del proceso transversal,

junto con los recursos empresariales alineados con
los retos estratégicos y con una visión clara de
objetivos hacia el cliente externo e interno,
aseguraremos el cumplimiento de los mismos,
manteniendo la eficiencia operacional y la
competitividad de la organización.
BUSINESS PROCESS MANAGEMENT “BPMS”
Un BPMS difieren en algunos aspectos de la forma en que

se han tratado las prácticas tradicionales de BPM.
Por ejemplo, los Diagramas de los Procesos BPMS son

diferentes a los diagramas de Procesos tradicionales en
los que se indica “lo que se debe hacer” (son meras
declaraciones de principios).
El hecho de que los diagramas en BPMS sean operativos

(la corriente de flujos irá irremisiblemente siguiendo el
diagrama) exige que se afine tanto que deben
determinarse todas las posibilidades que puedan darse.
Además, cada tarea del diagrama contiene el conjunto de acciones que

debe hacer en un determinado momento una persona (Tareas
Personales) o bien el sistema de forma automática (Tareas de Sistema),
aunque cada una de estas tareas contenga muchas acciones a realizar.
De igual forma, cada objeto del diagrama (tareas, compuertas,

eventos, etc. que están normalizados por la notación BPMN) debe ser
determinado al mínimo detalle, lo que hace casi imposible la
documentación de los procesos.
Por ejemplo, en una Tarea Personal, el ejecutor no será

necesariamente una persona o un cargo, deben poderse determinar
Roles Dinámicos, que actuarán según las circunstancias, o Grupos de
configuración muy sofisticada en función de múltiples criterios, y con
posibles Sustitutos en función de los casos posibles, etc.
En general, deben determinarse por cada

tarea los comportamientos que deben
asumir en función de todas las
circunstancias que puedan darse, y los
formularios deben contener todos los
campos, datos, documentos, instrucciones,
etc. necesarios para su realización.
BPMS
Un BPMS de última generación tiende a

estar conformado por una única
aplicación.
Al día de hoy, en la mayoría de los casos,

sigue estando conformado por un
conjunto de herramientas, aunque como
es natural evolucionarán hacia una sola
aplicación (tal como pasó con las
aplicaciones de gestión empresarial
tradicionales, que desembocaron en el
llamado ERP).
BPMS
Un BPMS puede no necesitar programación para

crear los procesos ni para las modificaciones
posteriores.
Mientras el Diagrama está siendo dibujado y los

atributos definidos (incluido sus Formularios),
BPMS construye, transparentemente para el
usuario, el código de programación para el
Motor que conducirá la ejecución del proceso.
Entonces no hay necesidad alguna de

programación ni intervención de técnicos de TI,
inclusive para llevar a cabo los procesos más
complejos.
BPMS
Con un BPMS de última generación la verdadera

documentación es el propio proceso. Ahí está TODO: el
diagrama, las cronometrías, los campos y documentos
que se utilizan, las reglas de negocio que se aplican, las
personas (o roles o perfiles o grupos, etc.) que
intervienen, las instrucciones a seguir por los
ejecutores, los automatismos, etc.
En los BPMS en los que los procesos se crean mediante

programación sí es necesaria la documentación.
La gente de negocio debe determinar mediante

documento escrito el procedimiento con todo detalle
para que IT (los programadores) puedan hacer su
trabajo.
BPMN
Principales elementos de la Notación
BPMN
Ejemplo de Modelado de Procesos
BPMN
BPMN
BPMN
BPMN
BPMN
BPMN
BPMN
BPMN
BPMN
BPMN
BPMN
DIAGRAMA DE FLUJO
Los diagramas de flujo son una manera de representar
visualmente el flujo de datos a través de sistemas de
tratamiento de información.
Los diagramas de flujo describen que operaciones y en

que secuencia se requieren para solucionar un problema
dado.
Un diagrama de flujo u organigrama es una

representación diagramática que ilustra la secuencia de
las operaciones que se realizarán para conseguir la
solución de un problema.
Los diagramas de flujo se dibujan generalmente antes de

comenzar a programar el código frente a la
computadora.
DIAGRAMA DE FLUJO
Los diagramas de flujo facilitan la comunicación entre los

programadores y la gente del negocio.
Estos diagramas de flujo desempeñan un papel vital en la

programación de un problema y facilitan la comprensión de
problemas complicados y sobre todo muy largos. Una vez que
se dibuja el diagrama de flujo, llega a ser fácil escribir el
programa en cualquier idioma de alto nivel.
Vemos a menudo cómo los diagramas de flujo nos dan ventaja

al momento de explicar el programa a otros, por lo tanto, está
correcto decir que un diagrama de flujo es una necesidad para
dejar mejor documentado un programa complejo.
DIAGRAMA DE FLUJO
Reglas para dibujar un diagramas de flujo
Los Diagramas de flujo se dibujan generalmente

usando algunos símbolos estándares; sin embargo,
algunos símbolos especiales pueden también ser
desarrollados cuando sean requeridos.
Algunos símbolos estándares, que se requieren con

frecuencia para diagramar programas de
computadora se muestran a continuación:
DIAGRAMA DE FLUJO
DIAGRAMA DE FLUJO
Símbolos gráficos dentro de los símbolos

fundamentales para la creación de diagramas de
flujo, los símbolos gráficos son utilizados
específicamente para para operaciones aritméticas y
relaciones condicionales.
La siguiente es una lista de los símbolos más

comúnmente utilizados.
DIAGRAMA DE FLUJO
Reglas para la creación de Diagramas
 Los Diagramas de flujo deben escribirse de arriba hacia

abajo, y/o de izquierda a derecha.
 Los símbolos se unen con líneas, las cuales tienen en la

punta una flecha que indica la dirección que fluye la
información procesos, se deben de utilizar solamente
líneas de flujo horizontal o verticales (nunca diagonales).
 Se debe evitar el cruce de líneas, para lo cual se quisiera

separar el flujo del diagrama a un sitio distinto, se
pudiera realizar utilizando los conectores. Se debe tener
en cuenta que solo se van a utilizar conectores cuando
sea estrictamente necesario.
DIAGRAMA DE FLUJO
 No deben quedar líneas de flujo sin conectar.
 Todo texto escrito dentro de un símbolo debe ser

legible, preciso, evitando el uso de muchas
palabras.
 Todos los símbolos pueden tener más de una línea

de entrada, a excepción del símbolo final.
 Solo los símbolos de decisión pueden y deben

tener mas de una línea de flujo de salida.
DIAGRAMA DE FLUJO DE DATOS
Un diagrama de flujo de datos (DFD) traza el flujo

de la información para cualquier proceso o sistema.
Emplea símbolos definidos, como rectángulos,
círculos y flechas, además de etiquetas de texto
breves, para mostrar las entradas y salidas de datos,
los puntos de almacenamiento y las rutas entre
cada destino.
Los diagramas de flujo de datos pueden variar

desde simples panoramas de procesos incluso
trazados a mano, hasta DFD muy detallados y con
múltiples niveles que profundizan progresivamente
en cómo se manejan los datos.
Se pueden usar para analizar un sistema existente o para
modelar uno nuevo. De forma similar a todos los mejores
diagramas y gráficos, un DFD puede con frecuencia "decir"
visualmente cosas que serían difíciles de explicar en palabras
y funcionan para audiencias tanto técnicas como no técnicas,
desde desarrolladores hasta directores.
Esa es la razón por la que los DFD siguen siendo tan

populares después de todos estos años. Aunque funcionan
muy bien para software y sistemas de flujo de datos, en la
actualidad no se aplican tanto para visualizar software o
sistemas interactivos, en tiempo real u orientados a bases de
datos.
Los diagramas de flujo de datos se popularizaron a finales

de la década de 1970, a partir del libro Structured Design
(Diseño estructurado), de los pioneros de la informática, Ed
Yourdon y Larry Constantine.
Lo basaron en los modelos computacionales de "gráficos de

flujo de datos" de David Martin y Gerald Estrin.
El concepto de diseño estructurado se popularizó en el

campo de la ingeniería de software, y con este también lo
hizo el método de DFD.
Se volvió más popular en los círculos de negocios que en

los círculos académicos, ya que se aplicó al análisis de
negocios.
Contribuyeron además dos conceptos relacionados:
 Análisis y diseño orientados a objetos (OOAD), propuesto

por Yourdon y Peter Coad para analizar y diseñar una
aplicación o sistema.
 Análisis de sistemas estructurados y método de diseño

(SSADM), un método de cascada para analizar y diseñar
sistemas de información.
Este riguroso enfoque de documentación contrasta con los

ágiles enfoques modernos, tales como Scrum y el Método de
desarrollo de sistemas dinámicos (DSDM).
Otros tres expertos que contribuyeron a este ascenso en la
metodología de los DFD fueron Tom DeMarco, Chris Gane
y Trish Sarson.
Colaboraron en diferentes combinaciones y fueron los

principales definidores de los símbolos y notaciones
usados para un diagrama de flujo de datos.
Edward Yourdon
Dos sistemas comunes de símbolos llevan el nombre de
sus creadores:
• Yourdon-Coad
• Tom DeMarco
• Gane-Sarson
Una diferencia importante en sus símbolos es que
Yourdon-Coad y Yourdon-DeMarco usan círculos para
procesos, mientras que Gane y Sarson usan
rectángulos redondeados, en ocasiones llamados
"grageas" (rombos).
Hay también otras variaciones de símbolos en uso,

por lo que lo importante es ser claro y constante en
Tom de Marco
las figuras y notaciones que uses para comunicarte y
colaborar con otros.
Usando las reglas o lineamientos para DFD de

cualquier convención, los símbolos representan los
cuatro componentes de los diagramas de flujo de
datos.
 Entidad externa: un sistema externo que envía o

recibe datos, comunicándose con el sistema que se
está diagramando.
Son las fuentes y destinos de la información que entra

o sale del sistema, podría ser una organización o
persona externas, un sistema de computadoras o un
sistema de negocios.
También se los conoce como terminadores, fuentes y

receptores o actores.
Generalmente se los dibuja en los bordes del diagrama

 Proceso: cualquier proceso que cambia los
datos y produce un resultado.
Podría realizar cálculos u ordenar datos basados

en una lógica o dirigir el flujo de datos en función
de reglas de negocios.
Se usa una etiqueta pequeña para describir el

proceso, por ejemplo "Enviar pago".
 Almacén de datos: archivos o repositorios que

conservan información para uso posterior, p.
ej., una tabla de base de datos o un formulario de
membresía.
Cada almacén de datos recibe una etiqueta simple, p.

ej., "Pedidos".
 Flujo de datos: la ruta que los datos toman entre
las entidades externas, los procesos y los
almacenes de datos.
Representa la interfaz entre los otros componentes y

se muestra con flechas, generalmente etiquetadas
con un nombre de datos corto, como "Detalles de
facturación"
Reglas y consejos para el DFD
• Cada proceso debe tener al menos una entrada y

una salida.
• Cada almacén de datos debe tener al menos una
entrada y una salida de flujo de datos.
• Los datos almacenados en un sistema deben
pasar por un proceso.
• Todos los procesos en un DFD pasan a otro
proceso o almacén de datos.
• Los datos almacenados en un sistema deben
pasar por un proceso.
Niveles y capas del DFD: de los diagramas de contexto al

pseudocódigo
Un diagrama de flujo de datos puede profundizar

progresivamente en más detalle por medio de niveles y
capas, concentrándose en una pieza en particular.
Los niveles de un DFD se numeran 0, 1 o 2 y en ocasiones

llegan incluso hasta el Nivel 3 o más.
El nivel necesario de detalle depende del alcance de lo que

estás tratando de lograr
Al Nivel 0 de un DFD también se lo llama

Diagrama de contexto. Es un panorama básico
de todo el sistema o proceso que se está
analizando o modelando.
Está diseñado para ser una vista rápida que

muestra el sistema como un único proceso de
nivel alto, con su relación con entidades
externas.
Debe ser entendido fácilmente por una amplia

audiencia, incluidas partes interesadas,
analistas de negocios, analistas de datos y
desarrolladores.
El Nivel 1 de un DFD brinda un desglose de

piezas más detallado del diagrama a nivel de
contexto.
Destacarás las principales funciones que el

sistema lleva a cabo, a medida que desgloses
el proceso de alto nivel del diagrama de
contexto en sus subprocesos.
Luego el Nivel 2 del DFD profundiza un

paso más hacia partes del Nivel 1.
Puede requerir más texto para alcanzar el

nivel necesario de detalle acerca del
funcionamiento del sistema.
Es posible el avance hacia los Niveles 3, 4 y más, pero ir más
allá del Nivel 3 es poco usual.
Hacerlo puede crear una complejidad que dificulte comunicar,

comparar o modelar de forma efectiva.
Con el uso de capas en el DFD, los niveles en cascada se

pueden anidar directamente en el diagrama, lo que
proporciona un aspecto más ordenado con fácil acceso a
profundizar en más detalle.
Al contar con un DFD con tanto detalle, los desarrolladores y

diseñadores pueden usarlo para escribir pseudocódigo, que es
una combinación de inglés y de lenguaje de codificación.
El pseudocódigo facilita el desarrollo del código real.

Ejemplos de cómo se pueden usar los DFD
Los diagramas de flujo de datos son muy apropiados para el
análisis y modelado de diversos tipos de sistemas en diferentes
campos.
DFD en ingeniería de software: Es aquí donde los diagramas de

flujo de datos tuvieron su principal arranque en la década de
1970. Los DFD pueden brindar un planteamiento enfocado hacia
el desarrollo técnico, en el cual se realiza más investigación previa
para llegar a la codificación.
DFD en análisis de negocios: Los analistas de negocios emplean

los DFD para analizar los sistemas existentes y encontrar
ineficiencias. La diagramación del proceso puede detectar los
pasos que, de otro modo, podrían pasar inadvertidos o no
comprenderse por completo.
DFD en la reingeniería de procesos de negocios: Los DFD

se pueden usar para modelar un flujo de datos mejor y
más eficiente a través de un proceso de negocios.
La reingeniería de procesos de negocios fue impulsada en

la década de 1990 para ayudar a las organizaciones a
reducir costos operativos, mejorar el servicio al cliente y
competir mejor en el mercado.
DFD en el desarrollo ágil: Los DFD se pueden usar para

visualizar y comprender los requisitos de negocios y
técnicos y planificar los siguientes pasos. Pueden ser una
herramienta simple pero poderosa para la comunicación y
colaboración a fin de enfocarse en un desarrollo rápido.
DFD en estructuras de sistemas: Cualquier sistema o proceso se

puede analizar en un detalle progresivo para mejorarlo en
aspectos tanto técnicos como no técnicos.
DFD vs. Lenguaje Unificado de Modelado (UML)
Mientras que un DFD ilustra cómo fluyen los datos a través de un

sistema, UML es un lenguaje de modelado usado en el Diseño de
software orientado a objetos para brindar una vista más
detallada.
Un DFD aún puede brindar un buen punto de partida, pero a la

hora de desarrollar el sistema, los desarrolladores pueden optar
por diagramas UML, como los diagramas de clases y los diagramas
de estructura para lograr la especificidad requerida.
DFD lógico vs. DFD físico
Estas son las dos categorías de un diagrama de flujo de

datos. Un DFD lógico visualiza el flujo de datos que es
esencial para que opere un negocio.
Se enfoca en el negocio y la información necesaria, no

en cómo funciona el sistema o cómo se propone que
funcione. No obstante, un DFD físico muestra cómo el
sistema está realmente implementado ahora o cómo lo
estará.
Por ejemplo, en un DFD lógico, los procesos serían

actividades de negocios, mientras que en un DFD físico,
los procesos serían programas y procedimientos
manuales.
MOMENTO PARA RETROALIMENTAR
MOMENTO PARA APLICAR
DFD -- Sistema de alquiler de bicicletas
Se trata de una nueva app, OpenBikes, que permite alquilar bicicletas
conectadas a Internet por toda la ciudad, llevan GPS, lo que permite
ubicarlas en un mapa y encontrar la bici más cerca. Además las
bicicletas llevan un candado controlado por la app.
Sistema de alquiler de bicicletas
Caso de uso textual
Un usuario quiere desplazarse usando la app OpenBikes. Ya se ha dado de alta y ha pagado
la suscripción mensual para poder utilizar el servicio. Abre la app en su móvil y ubica la
bicicleta más cercana gracias al mapa que muestra las bicicletas. Puede reservarla durante
unos minutos para estar seguro de que no se la lleve otra persona antes de que llegue.
Cuando llegue a la bicicleta, a través del sistema, desbloquea el candado y se puede ir con
ella. El tiempo de uso que le permite su suscripción es de 30 minutos. Si gasta más tiempo
en ello se le cobrará un suplemento. Al terminar su desplazamiento, debe atar la bici y
confirmar que el sistema ha detectado la nueva ubicación de la bicicleta y
su disponibilidad. Si no, se le podría cobrar un suplemento correspondiente al tiempo que
estuvo sin poder usarse.
Sistema de alquiler de bicicletas
 Confeccione el diagrama de contexto, nivel 0 y nivel 1 del Sistema.
Pueden utilizar algún programa para dibujar el diagrama, o simplemente con una hoja y
un lápiz.
Deben enviar su trabajo al correo del profesor antes

del Jueves 29 de Abril en formato PDF.
MUCHAS GRACIAS

Formato - Clase - Introducción A Requerimientos y Modelo de Negocios - Clase - PRO103 - 3603 - N5 - 9

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Formato - Clase - Introducción A Requerimientos y Modelo de Negocios - Clase - PRO103 - 3603 - N5 - 9

Cargado por

Copyright:

Formatos disponibles

INTRODUCCIÓN DE REQUERIMIENTOS

Mantén todos tus

Mantén tus dispositivos

Criterios de Evaluación: Preguntas y participación en clases.

1. DFD (diagramas de flujo de datos).

Casos de uso, clase,

Esta semana que paso hablábamos de los tipos de

Partimos de la base de que los casos de uso son

Muchas veces solemos caer en el error de vincular el

Los casos de uso se escriben con formatos diferentes

Los grados de formalidad con los que podemos escribir un caso

1. Breve: Descripción en unas pocas líneas.

También podríamos añadir otros

Suscripción LOGIN Administrador

En tránsito Usuarios operativos

El primer paso es la determinación de los Actores del

Para desarrollar el Diagrama de Casos de Uso del Negocio

Se conoce con el nombre de estereotipo ​ a

​Regularmente los estereotipos son basados en prejuicios que

Estos dos estereotipos (Casos de Uso del Negocio y el

El Modelo de Caso de Uso del Negocio implicará la

 Identificar los procesos en el negocio

Un candidato a Actor del Negocio es cualquier individuo,

• Clientes o potenciales clientes

De acuerdo con esta idea un Actor del Negocio

El nombre de un Actor del Negocio debe hacerse de

Los Actores del Negocio interactúan con el negocio enviando y

Un Caso de Uso del Negocio define qué debe ocurrir en el

Es decir, un Caso de Uso del Negocio describe una secuencia

Con estos tres estereotipos se puede desarrollar un

El Modelo de Objeto es creado a través de los Diagramas

Generalmente el primer flujo que inicia el Diagrama de

Actualmente hay mucha confusión en el mercado respecto al

Se piensa que adquiriendo tecnología para la automatización

La tecnología adquirida es sólo un conjunto de piezas de

Dado que en dichas implementaciones no se ha

BPM, que va más allá del aspecto tecnológico, es un

El BPM debe estar alineado con la estrategia, con la

La Gestión por Procesos es impulsada y hecha realidad

En un entorno tan competitivo como el actual, lleno de

La solución conlleva reaccionar ante la ineficiencia

Si potenciamos el concepto del proceso transversal,

Un BPMS difieren en algunos aspectos de la forma en que

Por ejemplo, los Diagramas de los Procesos BPMS son

El hecho de que los diagramas en BPMS sean operativos

Además, cada tarea del diagrama contiene el conjunto de acciones que

De igual forma, cada objeto del diagrama (tareas, compuertas,

Por ejemplo, en una Tarea Personal, el ejecutor no será

En general, deben determinarse por cada

Un BPMS de última generación tiende a

Al día de hoy, en la mayoría de los casos,

Un BPMS puede no necesitar programación para

Mientras el Diagrama está siendo dibujado y los

Entonces no hay necesidad alguna de

Con un BPMS de última generación la verdadera

En los BPMS en los que los procesos se crean mediante

La gente de negocio debe determinar mediante

Los diagramas de flujo describen que operaciones y en

Un diagrama de flujo u organigrama es una

Los diagramas de flujo se dibujan generalmente antes de

Los diagramas de flujo facilitan la comunicación entre los

Estos diagramas de flujo desempeñan un papel vital en la

Vemos a menudo cómo los diagramas de flujo nos dan ventaja

Se conoce con el nombre de estereotipo a

Regularmente los estereotipos son basados en prejuicios que