Facultad de Ingeniería

Ingeniería de Sistemas de Información.

Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia de la integración

de disciplinas modelado de negocio y requisitos para la arquitectura del
sistema.
Desarrollo
Taller integrador de disciplinas modelado de
negocio y requisitos
 Actividad

Tomando como referencia el caso de estudio, realizar la

integración de disciplinas modelado de negocio y requisitos
Consultas
Conclusiones
Conclusiones.

• Los beneficios del modelo de casos de uso del sistema incluyen

comunicación mejorada, ambigüedad reducida y una comprensión
común de los requisitos del sistema.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Cap. 3 y 4. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia de la

especificación de los casos de uso para la arquitectura del sistema.
Desarrollo
Documento especificación de casos de uso

• Una especificación de caso de uso proporciona detalles textuales

de un caso de uso. Se proporciona una descripción de ejemplo de
una especificación de caso de uso. Puede reutilizar y modificar la
descripción según se requiera en una especificación de caso de
uso.
Documento especificación de casos de uso
Documento especificación de casos de uso
 Actividad

Tomando como referencia el caso de estudio, especificar

los casos de uso.
Consultas
Conclusiones
Conclusiones.

• Los beneficios del modelo de casos de uso del sistema incluyen

comunicación mejorada, ambigüedad reducida y una comprensión
común de los requisitos del sistema.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Cap. 4. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia de la

especificación de los casos de uso para la arquitectura del sistema.
Desarrollo
Técnicas para capturar requisitos

• Entrevistas
• Cuestionarios
• Lluvia de ideas (Brainstorming)
• Prototipos
Priorización de requisitos

Criterios para priorizar requisitos:

• Riesgos de los requisitos.
• Comprende tanto la complejidad técnica como otros factores,
como incertidumbre del esfuerzo, especificación pobre o
facilidad de uso.
• Los riesgos de los requisitos es diferente a los riesgos del
proyecto.
• Naturaleza crítica.
• Se refiere a las funciones principales o de alto valor para el
negocio.
• Significativo para la Arquitectura.
• Desarrollo de habilidades.
Priorización de requisitos
Matriz de actividades vs. requisitos
Especificación de requisitos (SRS)
Especificación de requisitos (SRS)
 Actividad

Tomando como referencia el caso de estudio, especificar

requisitos.
Consultas
Conclusiones
Conclusiones.

• Los beneficios del modelo de casos de uso del sistema incluyen

comunicación mejorada, ambigüedad reducida y una comprensión
común de los requisitos del sistema.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Cap. 4. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia del modelo de

casos de uso para la arquitectura del sistema.
Desarrollo
Estructuración del modelo de Casos de uso del
sistema

• Existen tres razones para estructurar el modelo de casos de uso:

• Hacer que los casos de uso sean fáciles de entender.
• Permite extraer el comportamiento común encontrado en
varios casos de uso.
• Hacer que el Modelo de casos de uso sea fácil de mantener.
 Estructuración del modelo de Casos de uso del
sistema - Tipos de relaciones

• Asociación:
• Entre un actor y un caso de uso.
uc Modelo de Casos de Uso del Software

Realizar Ventas

Vendedor Cliente

• Generalización:
• Entre casos de uso y también entre actores.

uc Modelo de Casos de Uso del Software

Supervisor Vendedor
 Estructuración del modelo de Casos de uso del
sistema - Tipos de relaciones

• Include:
• Entre casos de uso.
• Obligatoria, siempre se va a realizar
• Parte del caso de uso Principal al caso de uso incluido.
• Ej. Cuando realizamos una venta, siempre debemos actualizar el
stock.
uc Modelo de Casos de Uso del Software

Realizar Ventas

Vendedor Cliente

«include»

ActualizaStock
 Estructuración del modelo de Casos de uso del
sistema - Tipos de relaciones

• Extend:
• Entre casos de uso.
• No obligatoria, es opcional: no siempre se va a realizar.
• Parte del caso de uso extendido al caso de uso principal
• Ej. Cuando realizamos una venta, a veces anulamos la
transacción.
uc Modelo de Casos de Uso del Software

Realizar Ventas

Cliente
Vendedor

«include»
«extend»

ActualizaStock

AnularVentas
Modelo de casos de uso del sistema
Modelo de casos de uso del sistema
Modelo de casos de uso del sistema
 Actividad

Tomando como referencia el caso de estudio, modelar

requisitos.
Consultas
Conclusiones
Conclusiones.

• Los beneficios del modelo de casos de uso del sistema incluyen

comunicación mejorada, ambigüedad reducida y una comprensión
común de los requisitos del sistema.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Cap. 4. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia de la

identificación de requisitos para la arquitectura del sistema.
Desarrollo
Estructuración del modelo de Casos de uso del
sistema

• Existen tres razones para estructurar el modelo de casos de uso:

• Hacer que los casos de uso sean fáciles de entender.
• Permite extraer el comportamiento común encontrado en
varios casos de uso.
• Hacer que el Modelo de casos de uso sea fácil de mantener.
 Estructuración del modelo de Casos de uso del
sistema - Tipos de relaciones

• Asociación:
• Entre un actor y un caso de uso.
uc Modelo de Casos de Uso del Software

Realizar Ventas

Vendedor Cliente

• Generalización:
• Entre casos de uso y también entre actores.

uc Modelo de Casos de Uso del Software

Supervisor Vendedor
 Estructuración del modelo de Casos de uso del
sistema - Tipos de relaciones

• Include:
• Entre casos de uso.
• Obligatoria, siempre se va a realizar
• Parte del caso de uso Principal al caso de uso incluido.
• Ej. Cuando realizamos una venta, siempre debemos actualizar el
stock.
uc Modelo de Casos de Uso del Software

Realizar Ventas

Vendedor Cliente

«include»

ActualizaStock
 Estructuración del modelo de Casos de uso del
sistema - Tipos de relaciones

• Extend:
• Entre casos de uso.
• No obligatoria, es opcional: no siempre se va a realizar.
• Parte del caso de uso extendido al caso de uso principal
• Ej. Cuando realizamos una venta, a veces anulamos la
transacción.
uc Modelo de Casos de Uso del Software

Realizar Ventas

Cliente
Vendedor

«include»
«extend»

ActualizaStock

AnularVentas
¿Usualmente, qué no se ubica en los
requerimientos?

• Estructura del sistema, tecnología de implementación

• Metodología de desarrollo
• Ambiente de desarrollo
• Lenguaje de implementación
• Reuso
• Es deseable que ninguna de los aspectos anteriores sea
restringido por el cliente: lógrelo!!!
Actividades de la Administración de
Requerimientos

• Análisis de Problemas
• Comprensión de las Necesidades de Usuarios
• Definición de Sistemas
• Administración de Alcances de Sistemas
• Refinamiento de la Definición de Sistemas
• Administración del Cambio de los Requerimientos
Tipos de requerimientos: en la práctica

• Requerimientos Funcionales: Son lo que los usuarios requieren

que el sistema haga. Los casos de uso son usados para establecer
lo que el sistema debe hacer. Especifican el comportamiento
esperado del sistema.

• Requerimientos No Funcionales: Son restricciones que especifican

propiedades del sistema, tales como facilidad de uso, restricciones
del entorno o de implementación, rendimiento, dependencias de
plataforma, facilidad de mantenimiento, extensibilidad, fiabilidad
y escalabilidad.
Clasificación de los Requerimientos - Requisitos
FURPS+

• Se utiliza el acrónimo FURPS (por las siglas en inglés) para

describir las principales categorías de requisitos:
• Funcionalidad (Funcionality)
• Uso (Usability)
• Confiabilidad (Reliability
• Desempeño (Performance)
• Soporte (Supportability)
• Se incluyen, además, otros requisitos, tales como:
• Restricciones de diseño
• Requisitos de implementación
• Requisitos de interfaz
• Requisitos físicos
Clasificación de los Requerimientos - Requisitos
FURPS+

• Funcionales:
Por ejemplo, para un Sistema de Ventas:
• R1: Mostrar descripción y precio de productos
• R2: Registrar venta de productos
• R3: Reducir stock cuando se realiza la venta
• Facilidad de uso
Por ejemplo:
• R1: El sistema deberá proporcionar ayudas en línea para
orientar en el uso de las interfaces.
• R2: Maximizar eficiencia mediante la navegación con teclado.
Clasificación de los Requerimientos - Requisitos
FURPS+

• Confiabilidad
Por ejemplo:
• R1: El sistema debe registrar los pagos a crédito autorizados
que se hagan a las cuentas por cobrar en un plazo de 24 horas,
aun cuando se produzcan fallas de energía o del equipo.
• R2: La cuenta del usuario se bloqueará por un lapso de 30
minutos luego de 4 intentos fallidos para evitar
vulnerabilidades en la seguridad del sistema.
• Rendimiento
Por ejemplo:
• R1: El tiempo máximo para mostrar el reporte de cuentas por
cobrar mediante un histograma es de 20 segundos
Clasificación de los Requerimientos - Requisitos
FURPS+

• Soporte
Por ejemplo:
• R1: El sistema debe operar de manera independiente del
• navegador que se utilice.
• R2: El sistema deberá estar orientado a que las actualizaciones
sólo se hagan en el sitio del servidor.
• Restricciones de diseño
Por ejemplo:
• El sistema deberá considerar, en su arquitectura, un modelo
tres capas, donde se definen tres componentes lógicos de
manera independiente: servicios de presentación o interfaz de
usuario, servicios de funcionalidad y servicios de datos.
Clasificación de los Requerimientos - Requisitos
FURPS+

• Requisitos de implementación
Por ejemplo:
• R1: El sistema debe desarrollarse con el lenguaje JAVA
• Requisitos de interfaz
Por ejemplo:
• R1: El sistema deberá proporcionar, para los diferentes
reportes solicitados, salidas en documentos electrónicos.
• Requisitos físicos
Por ejemplo:
• R1: Para que un cliente de la aplicación pueda ejecutar
procesos en línea considerados en el sistema, el punto de
acceso deberá cumplir con los requisitos mínimos.
Clasificación de los Requerimientos - Requisitos
FURPS+

• Requisitos de implementación
Por ejemplo:
• R1: El sistema debe desarrollarse con el lenguaje JAVA
• Requisitos de interfaz
Por ejemplo:
• R1: El sistema deberá proporcionar, para los diferentes
reportes solicitados, salidas en documentos electrónicos.
• Requisitos físicos
Por ejemplo:
• R1: Para que un cliente de la aplicación pueda ejecutar
procesos en línea considerados en el sistema, el punto de
acceso deberá cumplir con los requisitos mínimos.
 Actividad

Tomando como referencia el caso de estudio, modelar

requisitos.
Consultas
Conclusiones
Conclusiones.

• Los beneficios del modelado de requisitos incluyen comunicación

mejorada, ambigüedad reducida y una comprensión común de los
requisitos del sistema.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Cap. 4. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia de los requisitos

para la arquitectura del sistema.
Desarrollo
Conceptos básicos de la Ingeniería de Requisitos
Flujo de Captura de Requisitos
¿Dónde están ahora sus Requerimientos?
Los Requerimientos y los Documentos Asociados
Actividades Principales de la Obtención de
Requerimientos
Actividades Principales de la Obtención de
Requerimientos

• Identifica el Sistema
• Identificar Actores
• Identificar escenarios
• Identificar casos de uso y sus relaciones
• Refinar los casos de uso
• Identificar requerimientos no funcionales
• Identificar objetos participantes
Identificación del Sistema

• Desarrollo de un sistema no se hace tomando instantánea de una

escena (dominio)
• La definición de la frontera del sistema
Qué queda dentro y que fuera?
• Cómo podemos identificar el propósito de un sistema?
• Proceso de requerimientos:
Identificación de requerimientos: definición del sistema en
términos comprensibles para el cliente
Análisis: especificación técnica del sistema en términos
comprensibles por el desarrollador
Identificación de Actores

• Representan a un agente que interactúa con el sistema

• No son parte del sistema que se desarrolla
• Ingresan información al sistema
• Reciben información del sistema
• Ingresan y reciben información
Modelado de Requerimientos
Modelado de Requerimientos con Casos de Uso
del Sistema
Actores del Sistema
Paquetes
Casos de uso del sistema
Diagrama Casos de Uso del Sistema
 Actividad

Tomando como referencia el caso de estudio, modelar

requisitos.
Consultas
Conclusiones
Conclusiones.

• Los beneficios del modelado de requisitos incluyen comunicación

mejorada, ambigüedad reducida y una comprensión común de los
requisitos del sistema.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Cap. 4. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce como integrar la vista interna con

la vista externa del modelo del negocio.
Desarrollo
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
 Actividad

Tomando como referencia el caso de estudio, realizar el

Modelo del Negocio.
Consultas
Conclusiones
Conclusiones.

• El modelo del negocio está compuesto por dos vistas: la externa y la

interna. Para la vista externa, MCUN, utilizamos el diagrama de casos de
uso del negocio. Para la vista interna, MAN, utilizamos los diagramas de
actividades del negocio y clases del negocio.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Cap. 2. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce como integrar la vista interna con

la vista externa del modelo del negocio.
Desarrollo
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
 Actividad

Tomando como referencia el caso de estudio, realizar el

Modelo del Negocio.
Consultas
Conclusiones
Conclusiones.

• El modelo del negocio está compuesto por dos vistas: la externa y la

interna. Para la vista externa, MCUN, utilizamos el diagrama de casos de
uso del negocio. Para la vista interna, MAN, utilizamos los diagramas de
actividades del negocio y clases del negocio.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce como integrar la vista interna con

la vista externa del modelo del negocio.
Desarrollo
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
Taller de modelado de negocio
 Actividad

Tomando como referencia el caso de estudio, realizar el

Modelo del Negocio.
Consultas
Conclusiones
Conclusiones.

• El modelo del negocio está compuesto por dos vistas: la externa y la

interna. Para la vista externa, MCUN, utilizamos el diagrama de casos de
uso del negocio. Para la vista interna, MAN, utilizamos los diagramas de
actividades del negocio y clases del negocio.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.

Modelo de Anàlisis del Negocio

Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia de la vista interna

del modelo del negocio.
Desarrollo
Organización MAN

Trabajadores
del Negocio

Realizaciones
del Negocio
Entidades del
Negocio
Trabajadores del Negocio

Vendedor Cajero
Entidades del Negocio
Realizaciones del Negocio

Realizar venta RN_Realizar venta

(from Casos de Uso del Negocio)
Diagrama de Clases

consulta Producto
(from Entidades del Negocio)

emite

Volante
Vendedor (from Entidades del Negocio)
(from Trabajadores del Negocio)

emite

CDP
Cajero (from Entidades del Negocio)
(from Trabajadores del Negocio)
Diagrama de Actividad
 Actividad

Tomando como referencia el caso de estudio, realizar el

Modelo de Análisis del Negocio - MAN
Consultas
Conclusiones
Conclusiones.

• El modelo del negocio está compuesto por dos vistas: la externa y la

interna. Para la vista externa, MCUN, utilizamos el diagrama de casos de
uso del negocio. Para la vista interna, MAN, utilizamos los diagramas de
actividades del negocio y clases del negocio.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia de la vista externa

del modelo del negocio.
Desarrollo
Modelo de Negocio
Modelo de Negocio
Modelo de Casos de Uso del Negocio MCUN
Símbolos del Modelo de casos de uso
del Negocio
Organización del MCUN
Actores del Negocio
Casos de Uso del Negocio

Realizar venta
Objetivos del Negocio

Tener información confiable y en

forma oportuna

Incrementar las ventas en un 5%

Conocer el progreso de las ventas
mensualmente
 Diagrama General de Casos de Uso del
Negocio

Cliente Realizar venta Proveedor

(from Actores del Necogio) (from Casos de Uso del Negocio)
(from Actores del Necogio)
 Actividad

Tomando como referencia el caso de estudio, realizar el

Modelo de Casos de Uso del Negocio - MCUN
Consultas
Conclusiones
Conclusiones.

• El modelo del negocio está compuesto por dos vistas: la externa y la

interna. Para la vista externa, MCUN, utilizamos el diagrama de casos de
uso del negocio. Para la vista interna, MAN, utilizamos los diagramas de
actividades del negocio y clases del negocio.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.

Una fase se estructura en

iteraciones

En una Iteración se
desarrollan actividades de las
diferentes disciplinas
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia de la primera

disciplina de RUP.
Desarrollo
1ra Disciplina de RUP: Modelado del Negocio
Modelo de Casos de Uso del Negocio
 Modelo de Análisis del Negocio

Diagrama de actividades del negocio

 Modelo de Análisis del Negocio

Diagrama de actividades
Sub proceso
 Modelo de Análisis del Negocio

Diagrama de clases
del negocio
 Actividad

Tomando como referencia el caso de estudio, realizar:

(1) Modelo de Casos de Uso del Negocio - MCUN

(2) Modelo de Análisis del Negocio - MAN

Consultas
Conclusiones
Conclusiones.

• El proceso de desarrollo de software es un conjunto de actividades

necesarias para convertir los requisitos de usuario en artefactos que
conforman un producto software.
• El modelo del negocio está compuesto por dos vistas: la externa y la
interna. Para la vista externa, MCUN, utilizamos el diagrama de casos de
uso del negocio. Para la vista interna, MAN, utilizamos los diagramas de
actividades del negocio y clases del negocio.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.
Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia de la ingeniería de

software en el modelado de sistemas en una organización.
Desarrollo
El Modelo Arquitectura 4+1 Vistas

Vista Vista de
Estructural Implementación

Analistas/
Programadores
Diseñadores
Administración del Software
Estructura Usuarios Finales
Funcionalidad

Vista Casos de
Uso
Integradores de Sistemas Ingenieros de Sistemas
Performance Vista de Vista de Topología
Escalabilidad Proceso Despliegue Entrega, instalación
Throughput comunicación

*Se puede incorporar la Vista de Datos al modelo propuesto

 Modelamiento Visual con UML 2.0 (13 diagramas)

Diagrama Diagrama Diagrama Diagrama de

Tiempos Secuencias Caso de Uso Paquetes

Diagrama Diagrama
Comunicación Clases

Modelo
Diagrama Diagrama
Actividad Objetos

Diagrama de Diagrama
Visión Global de Diagrama Diagrama Estructura
Diagrama Componentes
Interacciones Despliegue Compuesta
Estados
 Las Buenas Prácticas y el RUP

• Enfoque Iterativo
• Guías para actividades y
artefactos
• Proceso enfocado en la
arquitectura
• Casos de uso que conducen
el diseño y la implementación
• Modelos que abstraen el
sistema
RUP: Un proceso basado en equipos

Proceso de
Ingeniería de
Software
El Producto rol

Interfaces
con otros
procesos

consume

artefacto produce actividad

Estructura del Proceso: Ciclo de Vida y Fases
Principales Hitos

Concepción Elaboración Construcción Transición

 Iteraciones y Fases

Una fase se estructura en

iteraciones

En una Iteración se
desarrollan actividades de las
diferentes disciplinas

Una iteración es una secuencia distinta de actividades basadas en un plan establecido

y criterios de evaluación, resultando en un ¿release? (interno o externo) ejecutable
La vida del Proceso Unificado
La vida del Proceso Unificado
El producto
El proceso
Características principales del proceso
Consultas
Conclusiones
Conclusiones.

• Una iteración es una secuencia de actividades con un plan establecido y

unos criterios de evaluación, cuyo resultado es una versión ejecutable
no orientada a la entrega.
• El producto software es un sistema compuesto por todos los
“artefactos” necesarios para representarlo de forma comprensible.
• El proceso de desarrollo de software es un conjunto de actividades
necesarias para convertir los requisitos de usuario en artefactos que
conforman un producto software.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Pearson Educación.

Facultad de Ingeniería
Ingeniería de Sistemas de Información.
Ingeniería de Software.
Ciencia de Datos.

Desarrollo de Sistemas
Empresariales
2023-1
Contenido.

Introducción

Desarrollo

Conclusiones

Referencias
Introducción
Introducción.

Procesando la información

Desarrollo de un Sistema de
Información

Muchos datos, poca información

Logro de Aprendizaje.

Al finalizar la sesión, el estudiante conoce la importancia del modelado de

sistemas en una organización.
Desarrollo
Procesando la información
Reglas para el proceso de un Sistema

Estratégico Táctico Operacional

◼ Análisis
◼ Acceso a
Valor Estratégico

Datos
◼ Colaboración

◼ 24x7

◼ Oportuno
◼ De fácil uso
◼ Vista de alto nivel
Número de decisiones
Importante!

UNA INFORMACIÓN ADECUADA

Gestión
EN EL LUGAR Y MOMENTO
ADECUADO INCREMENTA LA
EFECTIVIDAD DE CUALQUIER
Exploradores EMPRESA.

Consumidores
Analizando la Organización
Requerimientos por la empresa
Requerimientos por la empresa
Requerimientos por la empresa
Requerimientos por la empresa
 Reglas de Negocio de la empresa

Normalmente, todos los cursos tiene una duración de 24 horas, y se dicta en 8

sesiones de 3 horas cada una, dos sesión por semana. Puede existir cursos de
menor o mayor duración.
Los cursos se agrupan en ciclos, los cuales se inician normalmente la primera
semana de cada mes.
Un profesor no puede ser programado en mas de tres cursos por ciclo.
La evaluación de los cursos esta dada por un examen parcial (40%) y un examen
final (60%).
Para que un alumno reciba certificación, debe obtener un promedio mayor o
igual a 13.
Si un alumno desaprueba con un promedio mayor o igual que 10, tiene derecho
a rendir un examen de subsanación, la nota de este examen reemplaza a la
nota que más le conviene.
Ciclo de vida del software
Las Seis Buenas Prácticas

Buenas Prácticas
Desarrollar Iterativamente
Administrar requerimientos
Usar arquitectura de componentes
Modelar visualmente
Verificar la calidad continuamente
Gestionar los cambios
 ¿Qué es un Modelo?
• Un modelo es una simplificación de la realidad.
• Un modelo provee los planos del sistema.
• Un modelo podría ser estructural, enfatizando la organización del sistema.
• Un modelo podría ser dinámico, enfatizando la dinámica del sistema.
 ¿Por Qué Modelamos?
• Construimos modelos para comprender mejor el sistema que se
desarrollará.
• El modelado tiene como objetivos:
• Ayudar a visualizar cómo es o queremos que sea el sistema.
• Permitir especificar la estructura o el comportamiento del sistema.
• Proporcionar plantillas que guían en la construcción del sistema.
• Documentar las decisiones que se adopten.
La Importancia del Modelado

Construimos modelos para comprender

mejor el sistema que se desarrollará.

Otros...
Palabras
Maquetas
Fotos
Satelitales Planos
Modelos
mentales Diagramas
B U R M A
LA
OS
C H I N A TA IW AN

Bat an Is .
N
Gráficos

P
Bab u y an I s .

H
IL
IP
Estadísticos

P
IN
Lu zo n

E
PH
SOUTHEAST ASIA

S
E
T H A I L A N D

IL

A
IP
M A N IL A

PIN
NAM
C A M B O D I A
0 100 200 400 600 MI

ES
M in d or o

A
IN
S am ar
0 200 400 600 KM

T
I E

H
P an ay Ley t e
Cities

C
V C a pita l s -

an
and

law
Pa
H
N eg ro s
Tow ns 1 ,0 0 0, 0 00 an d ov e r -

T
S U L U

U
M in d ana o

Bandar Seri
A

Begawan
O
S E A
P A CI F I C

BRUNEI
E
S

S
S ulu
S A BA H
MA LA YS I A

M
Arc h ip elag o
OC EA N

AL
N an tu n a Is .

A
C E L E B E S T alau d I s .

YA
KUALA An am b as S an g ih e
LUMPUR Is la nd s

S
Ban y ak I s . Is .
WAK S E A

U
SARA

M
S I NG A PO RE

A
B O R N E O Halm ahe ra
Bat u Is . Bac an

T
I s.

R
MOLUCCA S c h o ut en

Me
Kar im at a
K A L I M A N T A N

S
SEA

A
nta
Is lan d s

BE
Arc h . O bi I s.

wa
Ban g k a

i Is.
S u la Is .

LE
Ban g g ai
CERAM SEA

Gulfof Bone
Arc h .
IRI

CE
Bill ito n
Bu r u
C er am AN
J AY
A

PAPUA NEW GUINEA

J A VA S E A
I N D JAKAR
TA
NG
BANDA SEA
Kai
Is . Aru

O N J
BANDU Semar
ang
Mad
ura Kan g ean
I s.
F L OR E S SE A
Is .

E S IA V A T an im b ar

A Bal i
S u m baw a
Sumba SAVU SEA T im or
I s.

S aw u I s .

I ND I A N O C E AN
A U S T R A L I A

Partituras Mapas
 Los “4” Principios del Modelamiento
• Los modelos creados influencian la forma de atacar el problema.
• Cada modelo puede expresarse en diferentes niveles de precisión.
• Los mejores modelos están conectados a la realidad.
• No es suficiente un único modelo.
 Principio 1: La elección del modelo es importante

• Los modelos creados influyen profundamente como el problema es

resuelto y la forma de la solución.
• En software, los modelos elegidos afectan la visión del mundo.
• Cada visión del mundo conduce a diferentes tipos de sistemas.

Modelo de Proceso Modelo de Despliegue Modelo de Diseño

 Principio 2: El nivel de precisión puede variar

• Cada modelo puede ser expresado en diferentes niveles de precisión.

• El mejor tipo de modelo permite escoger el grado de detalle, dependiendo de:
• ¿Quién ve el modelo?
• ¿Por qué necesita verlo?.

Vista del cliente Vista del Diseñador

 Principio 3: Modelos conectados a la realidad

• Todos los modelos simplifican la

realidad.
• Un buen modelo refleja las
características potencialmente fatales.
 Principio 4: Un único modelo no es suficiente

• Un simple modelo no es
suficiente. Cada sistema no
trivial o complejo se enfoca
mejor a través de un
conjunto limitado de
modelos relativamente Logical View Implementation View
independientes.
• Cree nuevos modelos que Analysts/Designers Programmers
Structure Software management
puedan ser construidos y
Use-Case View
estudiados de manera
End-user
separada, pero Functionality
interrelacionados.
Process View Deployment View
System engineering
System integrators System topology, delivery,
Performance, scalability, throughput installation, communication
 ¿Por Qué Modelar Visualmente?
• Capturar estructura y comportamiento
• Mostrar como se ensamblan los elementos
• Mantener diseño e implementación consistentes
• Ocultar o exponer detalles cuando sea apropiado
• Promover comunicación no ambigua
• UML: Un lenguaje para todos
Consultas
Conclusiones
Conclusiones.

• De acuerdo a las necesidades de la empresa los requerimientos del

sistema pueden variar.
• Una información adecuada en el lugar y momento adecuado incrementa la
efectividad de cualquier empresa.
• Un modelo es una simplificación de la realidad. Construimos modelos
para comprender mejor el sistema que se desarrollará.
GRACIAS
Referencias.

Sommerville, I. (2011). Ingeniería de Software. Pearson Educación.