1. Ingeniería en Sistemas Computacionales
Fundamentos de Ingeniería de Software
Unidad I: Modelo de Negocios
Este material está desarrollado para la asignatura Ingeniería de Software, de la carrera de Ingeniería en Sistemas
Computacionales, plan de estudios ISIC-2010-224
INGENIERÍA DE SOFTWARE

2. Temario de la Asignatura
INGENIERÍA DE SOFTWARE
Competencia: Desarrolla la habilidad para generar propuestas de
modelos de negocios de proyectos de software.

3. Definición de Ingeniería del Software (IS)
• La IS es una disciplina o área de la Informática o ciencias de
la Computación, que ofrece métodos y técnicas para
desarrollar, mantener y documentar software de calidad
qué, resuelve problemas de todo tipo, se ejecuta en
máquinas reales y satisface las necesidades del cliente.
INGENIERÍA DE SOFTWARE

4. ¿Qué es software?
• Programas de cómputo y su documentación asociada:
requerimientos, modelos de diseño y manuales de usuario
• El software puede ser desarrollado para un cliente en
particular o para un mercado general
INGENIERÍA DE SOFTWARE

5. ¿Quién lo hace?
• Los Ingenieros de Software lo construyen y lo mantienen, en
la sociedad industrial y las posteriores a ella casi todos los
profesionistas lo utilizan.
INGENIERÍA DE SOFTWARE

6. Características del Software
• El software se desarrolla o construye, no se manufactura
como otros productos.
• El software no se desgasta.
• La mayor parte del software en el mercado es construido a
la medida.
INGENIERÍA DE SOFTWARE

7. El modelo de negocios es el estudio de la organización
• Durante el proceso de modelado del negocio, se examina la
estructura de la organización y se observan los roles en la compañía
y como estos se relacionan.
• También se examina el flujo de trabajo de la organización, los
procesos principales dentro de la compañía y como ellos trabajan.
Además, se deben examinar las entidades externas, cualquier
individuo u otras compañías, y como interactúan con el negocio, y
observar las implicaciones de esas interacciones.
INGENIERÍA DE SOFTWARE

8. Conocimiento de la visión organizacional
• Al construir un sistema de software, se puede usar el modelo de
negocios para conocer y documentar que hace la organización.
Reingeniería de procesos del negocio
• Uno de los principales artefactos del modelo de negocios es el flujo
de trabajo de la organización. En base a esto el equipo de
reingeniería de negocios puede examinar los diagramas y analizar
posibles cambios de flujo de trabajos.
INGENIERÍA DE SOFTWARE

9. Entrenamiento
• Si un nuevo proceso es desarrollado o un nuevo miembro del
personal acaba de ingresar al equipo, los resultados del modelo de
negocios puede ser una herramienta de gran alcance para el
entrenamiento.
• Estos diagramas simples indican claramente, cuáles son las
responsabilidades de cada persona dentro del flujo de trabajo.
Ayudan a asegurar que cada uno tenga una visón común de los
procesos del negocio y de los papeles dentro de ellos.
INGENIERÍA DE SOFTWARE

10. ¿Porque modelar el negocio?
Contexto para una solución de software
• El modelado del negocio puede ayudarnos a comprender el contexto
del sistema que se esta construyendo.
• Mientras que esto puede sonar trivial, puede tener consecuencias
serias en el éxito o el termino de un proyecto de software. Si no
podemos entender el negocio, se pueden presumir conceptos
erróneos sobre lo que debe hacer el software y cómo puede ser
utilizado lo mejor posible por la comunidad del negocio.
El "mundo alrededor del sistema" es una consideración importante
al construir software.
INGENIERÍA DE SOFTWARE

11. ¿Cuándo será necesario hacer el modelo del negocio?
Si es necesario cuando:
 Cuando el grupo de trabajo es nuevo en la organización.
 Cuando la organización a enfrentado un reciente proceso de re-ingeniería de
negocios.
 Cuando la organización esta planificando un proceso de re-ingeniería de negocios.
 Cuando el software a construir será utilizado por una porción importante de la
organización.
 Existen flujos de trabajo complejos dentro de la organización que no están
documentados.
 Cuando se es un consultor en una organización en la cuál no se a trabajado antes.
INGENIERÍA DE SOFTWARE

12. ¿Cuándo será necesario hacer el modelo del negocio?
No es necesario cuando:
Cuando se tiene un conocimiento de la estructura de la
organización, de las metas, de la visión y de los clientes/usuarios.
Cuando el software a construir será usado por una pequeña parte
de la organización, y no tiene un efectos en el resto del negocio.
Cuando los flujos de trabajo de la organización están bien
documentados.
Cuando el tiempo lo permita, no todos los procesos tiene el tiempo
necesario para completar un análisis de negocio.
INGENIERÍA DE SOFTWARE

13. El modelo de negocios en el proceso iterativo
Existen dos formas para el acercamiento del modelo de negocios al proceso iterativo.
• La primera, es terminar primero el modelo de negocios y luego comenzar con las
iteraciones.
La ventaja es que permite comprender completamente el comportamiento del negocio
antes de comenzar el diseño del sistema como un todo.
La desventaja es que los usuarios o clientes del extremo pueden desear conseguir el
sistema rápidamente y no estarán dispuesto a esperar por el análisis del negocio
primero.
INGENIERÍA DE SOFTWARE

14. • La segunda forma, es incluir el modelo de negocios dentro del ciclo de vida.
Esto tiene la ventaja de dejarle estudiar la organización a medida que se crea el
sistema de software.
Claro que se corre el riesgo del mal entendiendo de la organización, y por lo tanto el
sistema de software en construcción no resuelve absolutamente las necesidades.
INGENIERÍA DE SOFTWARE

15. Objetivo
Comprender el conjunto de procesos de negocio que tienen lugar
dentro de una empresa, como paso previo a establecer los
requisitos del sistema a desarrollar.
¿Cómo consigue la empresa sus objetivos?
INGENIERÍA DE SOFTWARE

16. Proceso de Negocio
Una organización tiene una serie de objetivos que satisface a través
de Procesos de Negocio
Elementos de un proceso de negocio:
– Flujo de Tareas, Agentes, Información y Reglas
Negocio
• Reglas de Negocio regulan el funcionamiento de la empresa
– Describen restricciones y comportamientos
– NO son requisitos, pero influyen en ellos
INGENIERÍA DE SOFTWARE

17. Proceso del Negocio
Reglas del Negocio
• Determina políticas y estructuras de la información.
INGENIERÍA DE SOFTWARE

18. Sergio Sánchez Rios
Ejemplo
Empresa que vende productos bajo demanda
INGENIERÍA DE SOFTWARE

19. Etapas del modelado del negocio
1. Identificar y definir los procesos de negocio según los objetivos de la
organización.
2. Definir un caso de uso del negocio para cada proceso del negocio
(diagrama de casos de uso del negocio muestra el contexto y los límites
de la organización).
3. Identificar los roles implicados en los diferentes procesos del negocio
(diagrama de roles).
4. Modelar el flujo de tareas asociado a cada proceso de negocio mediante
escenarios (diagramas de secuencia) y diagramas de procesos
(diagramas de actividades) que muestran la interacción entre roles para
conseguir el objetivo.
5. Especificar las informaciones y actividades incluidas en cada diagrama de
actividad
INGENIERÍA DE SOFTWARE

20. Conceptos de modelado
Un actor del negocio, es cualquier persona o cualquier cosa externa
a la organización pero que obra recíprocamente con ella.
Por ejemplo, para su organización serian los clientes, sus acreedores,
sus inversionistas, o sus proveedores. Cada uno de estos actores
tienen un interés en las acciones de la empresa.
En UML se modela un actor del negocio usando la siguiente figura:
El icono representa a una persona, pero el
actor de negocios no es necesariamente un
individuo. Puede representar a un grupo de
personas o a una compañía.Cliente
(f rom Business Use-Case Model)
INGENIERÍA DE SOFTWARE

21. Un trabajador de negocios es un rol dentro de la organización. Importante, los
trabajadores del negocio son roles no posiciones. Una persona puede tener
varios roles, pero una sola posición.
La ventaja de diagramar roles es que estos no cambian con demasiada
frecuencia en el tiempo, las posiciones si.
En UML un trabajador de negocios se representa con el siguiente icono:
Se modela al trabajador del negocio para entender los
roles dentro del negocio y cómo interactúan
recíprocamente estos roles. Porque describiendo a cada
trabajador del negocio, podemos entender que
responsabilidades incluye ese rol, qué habilidades se
requieren para ese rol, y otros detalles.
Cliente
(f rom Business Use-Case Model)
INGENIERÍA DE SOFTWARE

22. Un caso de uso de negocio es un grupo de flujos de trabajo
relacionados dentro de la organización que proporcionan valor a los
actores del negocio.
Es decir los casos de uso de negocio dicen al lector lo que hace la
organización.
El sistema de todos los casos de uso del negocio para una
organización, debe describir totalmente lo que hace el negocio.
El UML los casos de uso del negocio se grafican con el siguiente icono:
Registrar Pedido
(from Business Use-Case Model)
INGENIERÍA DE SOFTWARE

23. Para cada caso de uso del negocio, se debe crear un cierto tipo de
informe que permite saber específicamente qué va a suceder dentro del
caso del uso.
• El flujo de trabajo se puede documentar de dos formas. La más
simple es crear una lista numerada, paso a paso de qué sucede
mientras que progresa el caso del uso.
• La problemática con la forma simple de escribir el flujo de trabajo, se
presenta cuando existe una gran cantidad de condiciones lógicas, lo
que provoca poca claridad.
• Para solucionar este problema se pueden utilizar los Diagramas de
Actividad, que nos permiten mostrar de forma grafica los flujos de
trabajo, la secuencia de los pasos y quien es responsable de realizar
cada paso.
INGENIERÍA DE SOFTWARE

24. Documentación
A cada caso de uso del negocio se le debe asociar una documentación que
sigue el siguiente formato
Proceso de Negocio
Objetivo
Descripción
Prioridad
INGENIERÍA DE SOFTWARE

25. Diagrama de casos de uso del negocios
Los diagramas de
casos de uso del
negocio muestran
casos de uso del
negocio, actores del
negocio y trabajadores
del negocio,
organizados y las
interacciones entre
ellos.
INGENIERÍA DE SOFTWARE

26. Una entidad de negocio es un objeto que la organización utiliza en su negocio o
produce durante el curso de su negocio. Las entidades incluyen cosas que los
trabajadores del negocio usan de forma cotidiana.
Para detectar las entidades de negocios, se pueden hacer preguntas como:
¿Qué productos la compañía produce?, ¿Qué servicios la compañía
proporciona? ¿Qué artículos la compañía compra para hacer su trabajo?,
¿Cuáles son los artículos que entrega o/ recibe de sus clientes?, ¿Qué artículos
se pasan de trabajador del negocio a otros trabajadores del negocio para
procesar?.
Otro truco es mirar los sustantivos en los nombres de los casos del uso del
negocio que usted ha definido. Para la mayor parte, cada sustantivo es una
entidad de negocio.
En UML las entidades de negocios se grafican de la siguiente forma:
INGENIERÍA DE SOFTWARE

27. Factura
(f rom Business Use-Case Model)
En UML las entidades de negocios se grafican de la siguiente forma:
Se pueden refinar las entidades de negocio agregando atributos. Un
atributo es un pedazo de información que describe la entidad. Por
ejemplo, una entidad llamada cuenta pudo tener atributos tales como
número de cuenta, tipo de la cuenta (corriente o ahorros), fecha
apertura, fecha cierre, y estado.
INGENIERÍA DE SOFTWARE

28. Los atributos se colocan bajo la entidad.
Recordar que en este paso solo se desea modelar el negocio, NO SE
DESEA CONSTRUIR UNA BASE DE DATOS.
INGENIERÍA DE SOFTWARE

29. Diagrama de Secuencia del negocio
Una vez definidos los agentes o roles participantes, se crean
escenarios para mostrar la colaboración entre estos.
Se pueden distinguir flujos exitosos y alternativo:
 Exitosos: los que muestran la tarea completada con éxito.
 Alternativo: son flujos que pueden ser distintos al exitoso,
generalmente son los de fracaso o falla.
En el diagrama de secuencias por defecto se refleja el flujo de eventos
exitoso. Solo cuando un flujo alternativo es complejo de entender se
debe ahondar en su definición mediante un diagrama de eventos
particular.
INGENIERÍA DE SOFTWARE

30. : Alumno : Encargada Finanzas
Entrega Cuponera y Dinero
Verifica Pago de Cuponera y Reviza Dinero
Timbra cuota a pago
Entrega Cuponera Validando Pago
En un diagrama de secuencia se utiliza la siguiente simbología:
Objetos del diagrama de secuencias son los
roles: actores y trabajadores del negocio.
Eventos que suceden entre lo diferentes
objetos.
Eventos de respuesta ante una acción, esto
mensajes son opcionales. (en el modelo de
negocio se recomienda que existan)
Línea de vida del objeto, determina la
participación de un objeto en una acción o
tarea
INGENIERÍA DE SOFTWARE

31. Diagrama de Actividades del negocio
Un diagrama de actividad es una manera de modelar el flujo de trabajo
de un caso del uso en forma gráfica. El diagrama muestra los pasos en
el flujo de trabajo, los puntos de decisión en el flujo de trabajo, quien es
responsable de terminar cada paso, y los objetos que son afectados
por el flujo de trabajo.
Este modelo debe incluir solo información relevante.
INGENIERÍA DE SOFTWARE

32. Diagrama de Actividades del negocio - Elementos
Actividad
Aparece como una caja con nombre y esquinas redondeadas.
Técnicamente éste es un tipo de estado que se abandona, no como
respuesta a algún evento que llega desde fuera, sino cuando termina la
actividad que representa.
NewActivity
INGENIERÍA DE SOFTWARE

33. Transición
Aparece como una flecha. Las transiciones en este diagrama
normalmente no se etiquetan, porque la transición es provocada por la
finalización de la actividad previa.
NewActivity
NewActivity2
Transición
INGENIERÍA DE SOFTWARE

34. Sergio Sánchez Rios
Barra de sincronización
Es una barra gruesa horizontal que describe la coordinación entre
actividades. Una vez que todas las actividades que tienen transiciones
dirigidas a la barra han terminado, pueden pasar la barra.
Almacenar
Devolución
Poner libro de
Vuelta en estantería
Barra de Sincronización
INGENIERÍA DE SOFTWARE

35. Diamante de decisión
Se utiliza para representar las decisiones, como respuesta a las guardas de
transición separadas que abandonan el mismo estado.
Marcas de creación y destrucción
Se utilizan para determinar el inicio y termino de una proceso.
INGENIERÍA DE SOFTWARE

36. Ejemplo:
INGENIERÍA DE SOFTWARE

37. Bibliografía
Software Engineering 6a. ed. Ian Sommerville. Pearson Education. 2000.
Cap. 6.
Ingeniería de Software Teoría y Práctica. Shari Lawrence Pfleeger- Pearson
Education. 2002.
Utilización de UML en ingeniería del software con objetos y componentes.
Perdita Stevens & Rob Pooley. Addison Wesley. 2002.
UML y Patrones una introducción al análisis y diseño orientados a objeto y al
proceso unificado. Craig Larman. Prentice Hall. 2002.
Pressman, R.S. Ingeniería del Software un Enfoque Práctico. McGraw-Hill.
Madrid, España. 2008.
Kendall E. K., Análisis y Diseño de sistemas. 1ª. Edición. Prentice Hall.
México. 2005.
INGENIERÍA DE SOFTWARE