El documento aborda el modelo de negocio en el contexto de la ingeniería del software, describiendo su evolución y los diferentes niveles de madurez del proceso que las organizaciones pueden alcanzar. Se destacan los componentes clave como personal, producto, proceso y proyecto, además de la importancia de los estándares y diagramas para la planificación y desarrollo de software. Finalmente, se enfatiza la utilidad de los diagramas de negocio para mejorar la efectividad, eficiencia, productividad y calidad de los procesos organizacionales.

1. El modelo de
negocio.
Ing. Verónica Rosales García.

2. 2.1
Definición
•Proceso de representación de
uno o más aspectos o
elementos de una empresa co
mo el propósito, su estructura,
funcionalidad, dinámica, lógica
de negocios y componentes
como fines, procesos, reglas,
objetos, actores y unidades
organizativas entre otras.

3. Evolución
del
Modelado
de Negocios.
• Se basa en un conjunto de
funciones de ingeniería del
software que deberían estar
presentes conforme
organizaciones alcanzan
diferentes niveles de madurez del
proceso. Para determinar el
estado actual de madurez del
proceso de una organización, se
utiliza un cuestionario de
evaluación y un esquema de
cinco grados.

4. NIVELES.
• Inicial. Se caracteriza según el caso. Se definen pocos procesos, y el
éxito depende del esfuerzo individual.
• Repetible. Se establecen los procesos de gestión del proyecto para
hacer seguimiento del coste, de la planificación y de la funcionalidad.
Para no repetir aplicaciones similares se aplica la disciplina necesaria
para el proceso.
• Definido. Documentación, estandarización, integración y aprobación
del proceso dentro de un proceso de software de toda una
organización.. En este nivel se incluyen todas las características
definidas para el nivel 2.
• Gestionado. Se recopilan medidas detalladas del proceso del
software y de la calidad del producto. Mediante la utilización de
medidas detalladas, se comprenden y se controlan
cuantitativamente tanto los productos como el proceso del software.
En este nivel se incluyen todas las características definidas para el
nivel 3.
• Optimización. Mediante una retroalimentación cuantitativa del
proceso, ideas y tecnologías innovadoras se posibilita una mejora del
proceso. En este nivel se incluyen todas las características definidas
para el nivel 4.

5. 2.2 Componentes
• Se centra en las cuatro P’s:
1. Personal.
2. Producto.
3. Proceso.
4. Proyecto

6. Personal.
Factor humano importante.
Se ha desarrollado un Modelo de madurez de la capacidad de gestión de personal para aumentar la
preparación de organizaciones del software para llevar a cabo las complicadas aplicaciones ayudando a
atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de
desarrollo de software.
El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el
personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento,
retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de
espíritu de equipo.

7. Producto
Producto para poder planificar un proyecto, se deben establecer los objetivos, el ámbito del producto,
soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información es imposible
definir unas estimaciones exactas del coste, valoración efectiva del riesgo, subdivisión realista de las tareas del
proyecto o una planificación del proyecto asequible que proporciona una indicación fiable del progreso.
El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto, y, más
importante, intenta abordar estas características de una manera cuantitativa.
Una vez que se han entendido los objetivos y el ámbito del producto, se consideran soluciones alternativas.

8. Proceso.
Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan
para el desarrollo del software.
El conjunto de tareas, hitos, productos del trabajo y puntos de garantía de calidad, permiten a las
actividades estructurales adaptarse a las características del proyecto de software, requisitos del equipo
del proyecto, las garantía de calidad del software, gestión de la configuración del software y medición
cubren el modelo de proceso.
Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del
proceso.

9. Proyecto.
Para gestionar un proyecto de
software con éxito, debemos
comprender qué puede ir mal
para hacerlo bien. Se define diez
señales que indican que un
proyecto de sistemas de
información está en peligro:
La gente del software no
comprende las necesidades de
los clientes.
El ámbito del producto está
definido pobremente.
Los cambios están mal
realizados.
La tecnología elegida cambia.
Las necesidades del negocio
cambian ó están mal definidas.
Las fechas de entrega no son
realistas.
Los usuarios se resisten.
Se pierden los patrocinadores ó
nunca se obtuvieron
adecuadamente.
El equipo del proyecto carece del
personal con las habilidades
apropiadas.
Los gestores y los
desarrolladores evitan buenas
prácticas y sabias lecciones.

10. 2.3 Estándares
•Actividad.
Realizar un cuadro comparativo con los estándares más utilizados para el
desarrollo del Modelo de Negocios en la Ingeniería del Software,
colocando: nombre, definición, características, usos, ventajas y
desventajas.
1. Lenguaje de Ejecución de Procesos de Negocios.
2. Lenguaje de Modelado Unificado
3. Líneas de Procesos Gestionadas por Eventos.
4. Notación para el Modelado de Procesos de Negocios.

11. Lenguaje de
Ejecución de
Procesos.
•Business Process Execution
Language (BPEL) es un lenguaje
ejecutable de la Organización para el
Avance de los Estándares de
Información Estructurada (OASIS)
para exportar e importar
información comercial utilizando
solo las interfaces disponibles a
través de servicios web.

12. •Se preocupa por el proceso abstracto de "programación en
grande", que involucra las interacciones de procesos de
transición de estado de alto nivel.
•Fue desarrollado para abordar las diferencias entre la
programación en grande y la programación en pequeño.
•También se conoce como lenguaje de ejecución de procesos
comerciales de servicios web (WS-BPEL), y a veces se escribe
como lenguaje de ejecución de procesos comerciales para
servicios web.

13. Objetivos.
Definir procesos comerciales
que interactúen con las
operaciones del servicio web.
Definir procesos de negocio
que empleen un lenguaje
basado en XML.
Definir un conjunto de
conceptos de orquestación
de servicios web para ser
utilizados tanto por las vistas
abstractas como ejecutables
de un proceso de negocio.
Proporcionar e implementar
regímenes de control
jerárquicos y gráficos.
Proporcione manipulaciones
de datos según sea necesario
para definir datos de proceso
y controlar el flujo
Soporta una metodología de
identificación para instancias
de proceso según lo definido
por los socios, al tiempo que
reconoce que pueden
cambiar
Apoyar la creación y
terminación implícitas de
instancias de proceso
Definir un modelo de
transacción de larga duración
basado en técnicas
comprobadas.
Utilice los servicios
basados en la web como
modelo para la
descomposición y el
ensamblaje de procesos.
Construir sobre estándares
de servicio web

14. Lenguaje de Modelado
Unificado.
•Es un lenguaje que permite
visualizar, modelar, construir y
documentar los elementos
que forman un sistema de
software usando objetos.

15. •El UML nos permite mediante diagramas, plasmar de una forma
detallada e inteligible la solución a un problema planteado.
•Está compuesto por diversos elementos gráficos que se combinan para
conformar diagramas.
•Los diagramas tienen como objetivo presentar diversas perspectivas de
un sistema.
•Un modelo UML describe lo que supuestamente hará un sistema, pero
no dice como implementar dicho sistema.

17. Líneas de Procesos
Gestionadas por
Eventos.
•Técnica de modelado de
procesos de negocio,
principalmente utilizada para el
análisis de procesos con la
intención de implementar una
planificación empresarial de
recursos.

18. •Emplean símbolos gráficos para presentarla estructura de flujo de
control de un proceso empresarial como una cadena de
eventos y funciones.
•La notación de este tipo de diagramas es muy sencilla, ya
que sólo consta de unos elementos
1. Evento
2. Función
3. Unidad organizativa
4. Información, material o recurso
5. Conector lógico
6. Flujo de control

19. Notación para el Modelado de Procesos de
Negocios.
•Es un lenguaje formal que permite modelar, simular y,
eventualmente, ejecutar un proceso de negocio.
•Determina y define los requerimientos del sistema.

20. 2.4 Diagramas
• La aplicación de diagramas de negocio demostrara ¿Cuán
importante resulta la aplicación de diagramas de negocio para un
programador?

21. Diagrama de
Negocios.
• El diagrama negocio
es un estándar
gráfico similar a los
organigramas que
pueden ser
entendidas con
facilidad por todas las
partes interesadas,
como analistas,
desarrolladores,
programadores y
gestores.

22. • Es por ello que se debe
conocer que un diagrama de
negocio es una notación que
forma parte de UML y que se
utiliza principalmente para
modelar procesos de negocio,
especificando:
1. La secuencia de
actividades que componen
los procesos de negocio.
2. Los actores que realizan las
actividades (opcional).
3. La información que fluye
de unas actividades a otras
(opcional).

23. •A partir del modelo del negocio al que el sistema software
debe dar soporte, se plantean los objetivos y requisitos del
sistema a desarrollar. La actividad inicial, que debe ser única,
indica donde comienza el proceso de negocio. Una actividad
final, de las que puede haber varias o ninguna (proceso sin
fin), indica donde puede terminar el proceso de negocio.

24. Elemento de un Modelo
de Proceso de Negocios.
• Entradas.
• Salidas.
• Recursos utilizados.
• Secuencia de Actividades.
• Eventos que dirigen el proceso.
• Roles/participantes involucrados.

25. Los beneficios de la aplicación de diagrama de negocio dentro de una
organización, es que gracias a ello existe:
•Efectividad en los procesos, es decir se concreta lo que ha de llevarse a
cabo.
•Eficiencia reutilización de procesos probados como más eficientes.
•Consistencia detección de tareas no realizables, prerrequisitos.
•Productividad reutilización de procesos más productivos.
•Ahorro asignación de costes (de tiempo, espacio y económicos) e
identificación de los procesos más ventajosos.
•Calidad, mejora general de los proceso.

26. Fuentes de consulta.
• https://mapachessistec.blogspot.com/2015/05/a-hrefhttp-subtema-1.html
• https://www.marcoteorico.com/curso/45/ingenieria-de-software/248/evolucion-
del-modelado-de-negocios
• https://es.slideshare.net/JosAntonioSandovalAc/fundamentos-de-ingenieria-de-s
oftware-unidad-1-modelo-de-negocios
• https://aguilarramosjesusfis.blogspot.com/2017/11/24-diagramas.html
• https://es.continuousdev.com/25239-business-process-execution-language-bpel-
7023
• https://www.ionos.mx/digitalguide/paginas-web/desarrollo-web/uml-lenguaje-u
nificado-de-modelado-orientado-a-objetos/
• https://www.studocu.com/es-mx/document/instituto-tecnologico-superior-de-ce
ntla/ingenieria-de-proyectos/tabla-comparativa-estandares-de-modelo-de-negoci
o/17631588