Análisis de

Requerimientos

SI903 Implementación de Sistemas

Análisis de Requerimientos

Da como resultado la especificación de las características operativas del

software, indica la interfaz de éste y otros elementos del sistema y establece
las restricciones que limitan al software.

El análisis de los requerimientos permite construir sobre los requerimientos

básicos establecidos durante las tareas de concepción, indagación y
negociación, que son parte de la ingeniería de los requerimientos
Análisis de
Requerimientos

• La atención se centra en qué,

no en cómo.
Ejemplos de preguntas

• ¿Qué interacción del usuario ocurre en una circunstancia particular?

• ¿Qué objetos manipula el sistema?
• ¿Qué funciones debe realizar el sistema?
• ¿Qué comportamientos tiene el sistema?¿Qué interfaces se definen?
• ¿Qué restricciones son aplicables?
Análisis de Requerimientos debe lograr:

• Describir lo que requiere el cliente

• Establecer una base para la creación de un diseño de software
• Definir un conjunto de requerimientos que puedan validarse una vez
construido el software.
 • Es un puente entre la descripción en
el nivel del sistema que se centra en
Análisis de éste en lo general o en la
funcionalidad del negocio que se logra
Requerimientos con la aplicación de software,
hardware, datos, personas y otros
elementos del sistema.
• Es importante observar que todos los
elementos del análisis de requerimientos
pueden rastrearse directamente hasta las
partes del del diseño.
• No siempre es posible la división clara entre
las tareas del análisis y las del diseño.
Análisis de
• Invariablemente, ocurre algo de diseño Requerimientos
como parte del análisis y algo de análisis se
lleva a cabo durante el diseño, y debe ser la
menor intersección posible y muy
controlada.
 Debe centrarse en los requerimientos que
sean visibles dentro del problema o dentro del
dominio del negocio. El nivel de abstracción
Reglas debe ser relativamente elevado.
prácticas para
el análisis Cada elemento del análisis de requerimientos
1/3 debe agregarse al entendimiento general de
los requerimientos del software y dar una
visión del dominio de la información, de la
función y del comportamiento del sistema
 Hay que retrasar las consideraciones de la
infraestructura y otros modelos no funcionales
Reglas hasta llegar a la etapa del diseño.

prácticas para
el análisis Debe minimizarse el acoplamiento a través del
sistema. Es importante representar las relaciones
2/3
entre las clases y funciones. Sin embargo, si el
nivel de “interconectividad” es extremadamente
alto, deben hacerse esfuerzos para reducirlo.
 Es seguro que el modelo de
requerimientos agrega valor para todos
los participantes. Cada actor tiene su
Reglas propio uso para el modelo.
prácticas para
el análisis Mantener el modelo tan sencillo como se
3/3 pueda. No genere diagramas adicionales
si no agregan nueva información. No
utilice notación compleja si basta una
sencilla lista.
Análisis de Dominio
Análisis de Requerimientos – SI903 Implementación de Sistemas
 Contexto:
• Si los requerimientos comunes
Análisis de pudieran reconocerse y aplicarse para
Dominio resolver
entonces
problemas
en
comunes,
Análisis de
Requerimientos sería más rápido.
Análisis de Dominio – ¿Qué es?

• Es la identificación, análisis y especificación de los

requerimientos comunes, a partir de un dominio de
aplicación específica, normalmente para usarlo
varias veces en múltiples proyectos dentro del
dominio de la aplicación.
Análisis de Dominio - Objetivo

• Encontrar o crear aquellos patrones de análisis que sean aplicables en

lo general, de modo que puedan volverse a usar varias veces.
La actividad: Análisis de Dominio

• Puede considerarse como una actividad sombrilla para el proceso de

hacer software.
• Significa que el análisis del dominio es una actividad de la ingeniería de
software que no está conectada con ningún proyecto de software.
Analista de Dominio

• Debe descubrir y definir patrones de análisis, clases de análisis e

información relacionada que pueda ser utilizada por mucha gente que
trabaje en aplicaciones similares, pero que no son necesariamente las
mismas.
Análisis de Dominio

• Las fuentes de conocimiento del dominio se mapean con el fin de

identificar los objetos que pueden reutilizarse a través del dominio.
Requerimientos no funcionales
Implementación de Sistemas SI903U
Requerimientos no funcionales

No se relacionan directamente con los servicios específicos que el sistema entrega a

sus usuarios.

Pueden relacionarse con propiedades emergentes del sistema, como fiabilidad,

tiempo de respuesta y uso de almacenamiento.

Pueden definir restricciones sobre la implementación del sistema.

 Como el rendimiento, la seguridad o la
Requerimientos disponibilidad, especifican o restringen por lo
no funcionales general características del sistema como un todo.

A menudo son más significativos que los

requerimientos funcionales individuales.

El fracaso para cubrir los requerimientos no

funcionales haría que todo el sistema fuera inútil.
Requerimientos no funcionales

Por lo general es más difícil relacionar

componentes con requerimientos no funcionales.
Tipos de Requerimientos no funcionales
Requerimientos de producto

• Especifican o restringen el comportamiento del software.

Requerimientos de la Organización

• Son requerimientos de sistemas amplios, derivados de políticas y

procedimientos en la organización del cliente y del desarrollador.
Requerimientos Externos

• Cubre todos los requerimientos derivados de factores externos al

sistema y su proceso de desarrollo.
Obtener requerimientos
Implementación de Sistemas SI903
Obtener requerimientos

• Es una actividad que se trabaja con clientes y usuarios finales.

Obtener
requerimientos
1. Descubrimiento de requerimientos

• Es el proceso de interactuar con los participantes del sistema para

descubrir sus requerimientos. También los requerimientos de dominio
de los participantes y la documentación se descubren durante esta
actividad.
2. Clasificación y organización de los
requerimientos
• Toma la compilación no estructurada de requerimientos, agrupa
requerimientos relacionados y los organiza en grupos coherentes.
• La forma más común de agrupar requerimientos es usar un modelo de
la arquitectura del sistema,
3. Priorización y Negociación de
Requerimientos
• Inevitablemente, cuando intervienen diversos participantes, los
requerimientos entrarán en conflicto.
• Esta actividad se preocupa por priorizar los requerimientos, así como
por encontrar y resolver conflictos de requerimientos mediante la
negociación.
4. Especificación de Requerimientos

• Los requerimientos se documentan y se registran, produciéndose

documentos de requerimientos.
Arquitectura y Diseño de un
Sistemas
Implementación de Sistemas SI903
Arquitectura de Sistemas

• Es el enlace crucial entre el diseño y la ingeniería de requerimientos, ya

que identifica los principales componentes estructurales en un sistema
y la relación entre ellos.
• Se describe la forma en que se organiza el sistema como un conjunto
de componentes en comunicación.
Arquitectura de Sistemas en dos niveles

1. La arquitectura en pequeño se interesa por la arquitectura de

programas individuales. En este nivel, uno se preocupa por la forma en
que el programa individual se separa en componentes.
Arquitectura de Sistemas en dos niveles

2. La arquitectura en grande se interesa por la arquitectura de sistemas

empresariales complejos que incluyen otros sistemas, programas y
componentes de programa. ales sistemas empresariales se distribuyen a
través de diferentes computadoras, que diferentes compañías
administran y poseen.
Implementación de Sistemas

Requerimientos
ING. PERCY CALIZAYA SI903U | FIIS | UNI 2
 Debe ser preciso para que
pueda actuar como un Describe lo que hará el
Un documento
contrato entre el sistema pero no cómo lo
estructurado que establece
comprador del sistema y el hará (objetivos pero no
los servicios que se espera
desarrollador de software. cómo se lograrán los
que proporcione el sistema
Tiene que ser comprensible objetivos).
para ambas partes.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 3

 • Una descripción abstracta del sistema
que sirve como base para (describe) el
diseño y la implementación detallados.
• Describe cómo se lograrán los
requisitos.
Especificación de • Los lectores principales serán los

diseño implementadores del sistema en lugar

de los usuarios o la administración.
• Los objetivos y restricciones
especificados en el documento de
requisitos deben ser rastreables hasta la
especificación de diseño (y desde allí
hasta el código).
ING. PERCY CALIZAYA SI903U | FIIS | UNI 4
Contenidos sugeridos para los
documentos de requisitos (1/2)
• Introducción: Describe la necesidad del sistema y lo contextualiza,
describiendo brevemente sus funciones externas (objetivo) y presentando una
justificación de su existencia. Describe cómo encaja el sistema en el negocio
general o en los objetivos estratégicos de la organización que encarga el
sistema.
• Objetivos del sistema: declaración informal de los objetivos específicos que
debe alcanzar el sistema.
• Restricciones del sistema: restricciones sobre cómo se pueden lograr los
objetivos (restricciones sobre el comportamiento del sistema y la libertad del
diseñador), por ejemplo, seguridad, hardware, lenguajes de programación,
estándares que se deben seguir. Incluye requisitos de calidad como
mantenibilidad, disponibilidad, etc.
Interfaces con el entorno: límite del sistema, entradas, salidas
•I N G . P E R C Y C A L I Z A Y A SI903U | FIIS | UNI 5
Contenidos sugeridos para los
documentos de requisitos (2/2)
• Requisitos funcionales: "Declaraciones de deber". Los servicios prestados para el
usuario. Incluye requisitos de tiempo y precisión.
• Prioridades: guía las compensaciones y las decisiones de diseño si no se pueden
cumplir por completo todos los requisitos y restricciones.
• Modelos del sistema: muestra las relaciones entre los componentes del sistema y el
sistema y su entorno.
• Evolución del sistema: suposiciones fundamentales sobre cambios anticipados
debido a la evolución del hardware, necesidades cambiantes del usuario, etc.
• Modelos de sistema: Modelos a nivel de sistema del comportamiento de caja negra
(sin diseño) del sistema. Puede incluir varias vistas del comportamiento del sistema.
• Glosario: Definiciones de términos técnicos utilizados en el documento.
• ¿Otros?
ING. PERCY CALIZAYA SI903U | FIIS | UNI 6
Atributos de un buen documento de
requisitos (1/2)
• Legible y comprensible para clientes, usuarios, partes interesadas y
desarrolladores/diseñadores/arquitectos/testers
• Especifica solo el comportamiento del sistema externo (caja negra)
• Estructurado para ser fácil de cambiar
• Especifica objetivos y restricciones.
• Capaz de servir como referencia para el mantenimiento del sistema.
• Incluye supuestos y justificación de los contenidos cuando
corresponda.
ING. PERCY CALIZAYA SI903U | FIIS | UNI 7
Atributos de un buen documento de
requisitos (2/2)
• Consistente, completo, inequívoco, realista, sin diseño y
comprobable.
• Especifica respuestas aceptables a eventos no deseados
• Especifica lo que no se debe hacer y lo que se debe hacer
• Especifica subconjuntos incrementales si se desea o funcionalidad
mínima y máxima
• Especifica los cambios anticipados en el futuro (tanto para el
entorno como para el sistema)
ING. PERCY CALIZAYA SI903U | FIIS | UNI 8
Los requisitos deben ser consistentes
1/2
• Un requerimiento es consistente si no entra en contradicción ni
en conflicto con otros requerimientos
• Para evitarlas, hay que revisar TODOS los requerimientos, unos
contra otros
• Antes de iniciar la construcción ya deberían haberse resuelto
todas las inconsistencias
• Hay que tener cuidado al modificar el requerimiento, porque
se pueden producir nuevas inconsistencias.
ING. PERCY CALIZAYA SI903U | FIIS | UNI 9
Los requisitos deben ser consistentes
2/2
¿Qué opinan de estos requerimientos?
• El sistema de compras debe hacer interface con el sistema de
tesorería (El sistema de tesorería es usado por la Gerencia
financiera, y registra los egresos de la institución), sacando la
información de los pagos realizados a los proveedores
• El sistema emitirá mensajes al usuario al menos cada 60
segundos
• El sistema tendrá un tiempo de respuesta rápido.
ING. PERCY CALIZAYA SI903U | FIIS | UNI 10
Los requisitos deben estar completos
1/2
Un requerimiento es completo si:
• No incluye expresiones como: “...por determinar”, “...que se
definirá...”, “...muchos”, “...pocos”, “...algunos”
• Se han definido todos los valores esperados en todos los
escenarios posibles.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 11

Los requisitos deben estar completos
2/2
¿Qué opinan de estos requerimientos?
• El sistema debe estar disponible 24x7x365
• Una vez obtenidos los dos números, se efectúa la operación aritmética
correspondiente
• Todos los indicadores deben ser verdes cuando superen el 90%. Cuando
superen el 60% deben ser ámbar, y cuando sean menores de 60% deben
ser rojos
• El sistema debe permitir hacer backups en frío
• El listado de clientes debe contener nombre y dirección. Este reporte
será enviado por email a los gerentes mensualmente.
ING. PERCY CALIZAYA SI903U | FIIS | UNI 12
Los requisitos no deben ser ambiguos
(1/2)
• Un requerimiento es inequívoco (no ambiguo) si cada
requerimiento descrito tiene una única interpretación.
• Cada característica del producto final debe ser descrita
utilizando un término único y, en caso de que se utilicen
términos similares en distintos contextos, se deben indicar
claramente las diferencias entre ellos.
• La ambigüedad da rienda suelta a la imaginación.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 13

Los requisitos no deben ser ambiguos
(2/2)
• Se debe incluir un glosario en el que se indica cada término, a
fin de no definirlo en la descripción del requerimiento.
• Debemos preguntarnos: ¿si este requerimiento lo leyera una
persona que no conoce el negocio, podría interpretarlo de otro
modo?

ING. PERCY CALIZAYA SI903U | FIIS | UNI 14

Los requisitos no deben incluir diseño
(1/2)
Generar archivo en Excel para Control de gastos de los viáticos del
personal.
• ¿Estás seguro que lo quieres en Excel?

El sistema debe tener una pantalla de mantenimiento de proveedores

• ¿Es la única forma de resolver el problema?

Reporte de accionistas con quiebre a tres niveles

• ¿Cuál es exactamente la necesidad?

ING. PERCY CALIZAYA SI903U | FIIS | UNI 15

Los requisitos no deben incluir diseño
(2/2)
Un requerimiento no debe tener rastros de componentes o
algoritmos. No debe asumirse cantidad de reportes o consultas,
ni información sobre “cómo” se implementará el requerimiento.

Cómo Qué

ING. PERCY CALIZAYA SI903U | FIIS | UNI 16

Los requisitos deben ser comprobables
• Un requisito no comprobable:
• El sistema debe ser fácil de usar por parte de los controladores de
experiencia y debe estar organizado de tal manera que se minimicen los
errores del usuario.

• Un requisito comprobable:
• Los controladores experimentados podrán utilizar todas las funciones del
sistema después de un total de dos horas de formación. Después de esta
capacitación, el número promedio de errores cometidos por usuarios
experimentados no deberá exceder de dos por día.
ING. PERCY CALIZAYA SI903U | FIIS | UNI 17
Desarrollar buenos requisitos es muy difícil

ING. PERCY CALIZAYA SI903U | FIIS | UNI 18

Tipo de Especificaciones (Requisitos y
diseño)
Informal
• Forma libre, lenguaje natural
• La ambigüedad y la falta de organización pueden conducir a
que estén incompletos, a la incoherencia y a los
malentendidos.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 19

Tipo de Especificaciones (Requisitos y
diseño)
Formateado
• Sintaxis estandarizada
• Verificaciones básicas de consistencia e integridad (aunque
limitadas)
• La semántica imprecisa implica que pueden estar presentes
otras fuentes de error

ING. PERCY CALIZAYA SI903U | FIIS | UNI 20

Sintaxis del requerimiento
Para requerimientos funcionales

• Nombre:
VERBO + SUJETO + COMPLEMENTO

• Descripción:
<<ESTÍMULO>> → <<RESPUESTA>>

ING. PERCY CALIZAYA SI903U | FIIS | UNI 21

Un ejemplo de un requerimiento
• Mostrar información de impugnación

• Cuando se haya impugnado el proceso de selección, el sistema

mostrará la información de los estados de la impugnación: Apelación,
revisión y resultados

ING. PERCY CALIZAYA SI903U | FIIS | UNI 22

Recomendación
• Mantener frases y párrafos cortos para el nombre del requerimiento.
Usar la voz activa (Verbo + Sujeto + Complemento). Usar las reglas de
gramática, ortografía y puntuación. Usar términos consistentes y
definirlos en un glosario o diccionario de datos.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 23

Tipo de Especificaciones (Requisitos y
diseño)
Formal
• Sintaxis y semántica rigurosamente definidas
• Forma precisa, quizás matemática.
• Elimina la imprecisión y la ambigüedad, pero puede ser difícil de
leer sin una amplia formación
• Potencialmente proporciona una base para verificar
matemáticamente la equivalencia entre la especificación y la
implementación.
• ¿Distancia semántica demasiado grande?
ING. PERCY CALIZAYA SI903U | FIIS | UNI 24
Argumentos a favor de las
especificaciones formales (1/2)
• Un programa (software) es un objeto matemático

• Un lenguaje de programación es un lenguaje matemático

ING. PERCY CALIZAYA SI903U | FIIS | UNI 25

Afirmaciones de entrada-salida
(condiciones previas y posteriores) 1/2
• S {P} Q
• Si S se cumple antes de la ejecución de S, entonces Q se cumple
después
• Ejemplos:

ING. PERCY CALIZAYA SI903U | FIIS | UNI 26

Afirmaciones de entrada-salida
(condiciones previas y posteriores) 2/2

ING. PERCY CALIZAYA SI903U | FIIS | UNI 27

Especificaciones del modelo abstracto
La especificación incluye:
• Modelo
• Propiedades invariantes de ese modelo.
• Para cada operación:
nombre
parámetros
valores devueltos
• Condiciones pre y post en las operaciones

ING. PERCY CALIZAYA SI903U | FIIS | UNI 28

Ejemplo: Z
• Las especificaciones Z se componen de "esquemas"
• Un esquema es una especificación con nombre, relativamente
corta, con dos partes:
• Sobre la línea: la definición de las entidades de datos
• Debajo de la línea: la definición de las constantes que se
mantienen en esas entidades de datos

ING. PERCY CALIZAYA SI903U | FIIS | UNI 29

Argumentos a favor de las
especificaciones formales (2/2)

Por lo tanto, podemos probar propiedades sobre el programa

• Tal como hace lo que se supone que debe hacer
• No hace nada dañino

Construir un modelo como lo hacen los ingenieros, pero

necesita matemáticas discretas en lugar de continuas

ING. PERCY CALIZAYA SI903U | FIIS | UNI 30

Z: Definición del modelo abstracto 1/2

• La declaración dice que la biblioteca tiene dos partes visibles de su estado:

• books es un conjunto de BOOKS, que son elementos atómicos
• status es una función parcial que asigna un BOOK a STATUS (que es otro elemento atómico que puede
tomar valores dentro o fuera)

• Lo constante es que el conjunto de books es precisamente el mismo que el dominio de

la función status
• cada book en la Library tiene exactamente un Status
• dos books pueden tener el mismo status

ING. PERCY CALIZAYA SI903U | FIIS | UNI 31

Z: Definición del modelo abstracto 2/2

• Ejemplo de un estado legal para Library es:

• books = { “Principios de matemática”, “seguridad”}
• status = (“Principios de matemática” -> dentro, “seguridad” -> fuera)

ING. PERCY CALIZAYA SI903U | FIIS | UNI 32

Z: Definiendo operaciones

• La declaración de △ Library dice que la operación modifica el status de la

Library
• book? está dentro
• Se indica el valor luego de la operación
• Primero se define la condición previa a la operación: El book debe estar dentro
• Luego se define la semántica del préstamo, se actualiza el status del book a
“fuera”.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 33

Especificaciones del modelo abstracto
• Cree un modelo abstracto del comportamiento del software
requerido usando tipos definidos matemáticamente (quizás
usando axiomas) (por ejemplo, conjuntos, relaciones)
• Definir operaciones mostrando los efectos de esa operación en
el modelo

ING. PERCY CALIZAYA SI903U | FIIS | UNI 34

Especificaciones de intención
Especificación centrada en el ser humano
• Integra conceptos en
• Factores humanos
• Ingeniería de sistemas/teoría de sistemas
• Psicología cognitiva (cómo los expertos resuelven problemas)
• El objetivo es que las especificaciones apoyen la resolución de problemas humanos
• Información necesaria fácil de encontrar
• Mejorar la comunicación y la revisión de expertos
• Supuestos de documentos, justificación del diseño
• Trazabilidad al soporte
• V&V
• Proceso de cambio y actualización
• No hacer cumplir un proceso específico

ING. PERCY CALIZAYA SI903U | FIIS | UNI 35

Diferentes roles requieren diferentes
vistas del sistema

Why

ING. PERCY CALIZAYA SI903U | FIIS | UNI 36

Ejemplo de Contenidos Potenciales

ING. PERCY CALIZAYA SI903U | FIIS | UNI 37

Level 1 (Vista del cliente) Ejemplos
Level 1 Environment
• Describir los ambientes en cada interacción
• Supuestos sobre el ambiente:
• 1: La información de altitud está disponible para los intrusos con una precisión mínima de 100 pies
• 2: Todas las aeronaves tienen un número legal de identificación

Level 1: Operator
• Tareas y responsabilidades del piloto
• Requerimientos del Operador: Los avisos se ejecutarán de tal manera que se minimice la desviación de la
aeronave sin su autorización.

• Human Machine Interface Requirements

• Se emitirá una alerta visual roja en el campo de visión principal de cada piloto para los avisos de
advertencia.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 38

Requerimientos y Objetivos Funcionales
• Level 1 Functional Goals:
• Proporcionar opciones de sistemas de prevención de colisiones
asequibles y compatibles para un amplio espectro de usuarios del
espacio aéreo nacional.
• Level 1 Functional Requirements
• Proporcionará protección para evitar colisiones para dos aeronaves
que se acerquen horizontalmente a cualquier velocidad hasta 1200
nudos y verticalmente hasta 10000 pies por minuto.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 39

SpecTRM-RL [Link]

• Especificación de requisitos combinados y lenguaje de modelado.

• Una máquina de estado (lógica formal) con una notación específica
de dominio encima
• Incluye un lenguaje de modelado de tareas.
• Puede agregar otras notaciones y visualizaciones de máquinas
de estado
• Hace cumplir o incluye la mayoría de nuestros criterios de
integridad

ING. PERCY CALIZAYA SI903U | FIIS | UNI 40

Gráfico visual general del sistema

ING. PERCY CALIZAYA SI903U | FIIS | UNI 41

 SpecTRM-RL Modelo de Sistema de Control de
Actitud HETE (High Energy Transient Experiment)

ING. PERCY CALIZAYA SI903U | FIIS | UNI 42

Tipos de análisis posibles en las
especificaciones SpecTRM-RL
• Ejecución, animación y visualización del modelo (puede actuar
como un prototipo ejecutable)
• Completo
• Análisis de riesgo
• Análisis de tareas humanas
• Análisis de cobertura de prueba y generación de casos de
prueba
• Generación automática de código

ING. PERCY CALIZAYA SI903U | FIIS | UNI 43

Especificaciones de objeto vs de control
1/2
• Para el procesamiento humano, el formato de especificación
debe coincidir con la estructura del problema (distancia
semántica)
Orientada al control Orientada al objeto
Comience por Comience por
definir las definir los objetos
funciones involucrados y las
necesarias operaciones en
esos objetos.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 44

Especificaciones de objeto vs de control
2/2
• Especificación de control: indica (1) cómo se comporta el
software/sistema cuando se detecta un evento o una señal de
control y (2) qué procesos se invocan como consecuencia de la
ocurrencia del evento. A veces usa máquinas de estado y un
diagrama de transición de estado.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 45

Situación actual 1/2
• La informática ha convencido a todos de que solo las
especificaciones orientadas a objetos son útiles o "buenas".
• Ventajas de tener un lenguaje de especificación para todo:
• Problemas de aprendizaje reducidos
• Los desarrolladores de herramientas obtienen ganancias
mucho mayores y tienen más clientes potenciales
• Se elimina la toma de decisiones sobre qué lenguaje usar

ING. PERCY CALIZAYA SI903U | FIIS | UNI 46

Situación actual 2/2
• Desventajas:
• Ha llevado a la optimización en problemas orientados a objetos, pero
a grandes problemas en programas orientados a control.
• Inhibe las habilidades de resolución de problemas de los usuarios
para diferentes tipos de problemas ("distancia semántica" maximizada
casi hasta el punto de ser imposible)
• MBSE potencial limitado (p. ej., tipos limitados de análisis posibles)
• Se han estandarizado con un lenguaje de especificación antiguo y
cualquier progreso, incluso en lenguajes orientados a objetos, se ha
detenido.
ING. PERCY CALIZAYA SI903U | FIIS | UNI 47
Resumen 1/3
• Los requisitos actúan como un contrato entre el comprador y el
desarrollador. Tiene que ser comprensible para ambos.
• Diferentes personas (roles) necesitan diferentes vistas
(modelos) de un sistema
• No solo refinamientos del mismo modelo.
• MBSE proporciona un solo modelo para hacer todo
• Los modelos deben ser consistentes y trazables entre ellos.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 48

Resumen 2/3
• La especificación de los supuestos subyacentes y la justificación
de las decisiones deben documentarse y de manera que la
información pueda localizarse fácilmente cuando sea
necesario. Necesidad de documentar "por qué" de alguna
manera.
• La distancia semántica (“intuitiva”) afecta la comprensión.

ING. PERCY CALIZAYA SI903U | FIIS | UNI 49

Resumen 3/3
• El formato y el contenido de las especificaciones afectan la
capacidad para resolver problemas
• Usar modelos y lenguajes de especificación que coincidan con
el problema a resolver (tipo de sistema que se está diseñando)

ING. PERCY CALIZAYA SI903U | FIIS | UNI 50

Lenguaje de Modelado Unificado
- UML
Implementación de Sistemas SI903
 Lenguaje de Modelado Unificado - UML

• Es “un lenguaje estándar para • Booch, G., J. Rumbaugh y I. Jacobsen, The Unified
Modeling Language User Guide. 2a. ed., Addison-
escribir diseños de software. El Wesley, 2005.

UML puede usarse para

visualizar, especificar, construir
y documentar los artefactos de
un sistema de software
intensivo”

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 2

Lenguaje de Modelado Unificado - UML

Los Analistas de Sistemas de software crean diagramas de UML

para ayudar a los desarrolladores de software a construir el
software

Si entiende el vocabulario del UML (los elementos pictóricos de

los diagramas y su significado) puede comprender y especificar
con mucha más facilidad un sistema, y explicar su diseño a otros

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 3

 Diagrama de Caso de Uso
UML
Análisis de Sistemas

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 4

 Diagrama de Caso de Uso UML
• Ayudan a determinar la funcionalidad y características del software desde
la perspectiva del usuario.

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 5

 • Funciones:
Aplicación de • Descargar un archivo de música MP3 y almacenarlo en
sw que la biblioteca de la aplicación.
• Capturar música de streaming (transmisión continua) y
gestiona almacenarla en la biblioteca de la aplicación.
• Gestionar la biblioteca de la aplicación (por ejemplo,
archivos de borrar canciones u organizarlas en listas de
reproducción).
música digital • Quemar en CD una lista de las canciones de la
biblioteca.
• Cargar una lista de las canciones de la biblioteca en un
iPod o reproductor MP3.
• Convertir una canción de formato MP3 a formato AAC
y viceversa.

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 6

 • Un caso de uso describe la manera en la que un usuario
interactúa con el sistema, definiendo los pasos requeridos
Diagrama de para lograr una meta específica
Caso de Uso • Las variaciones en la secuencia de pasos describen varios
escenarios.
UML • Un diagrama UML de caso de uso es un panorama de todos
los casos de uso y sus relaciones.
• El mismo proporciona un gran cuadro de la funcionalidad
del sistema.

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 7

 Diagrama de Caso
de Uso

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 8

 La figura de palitos representa a un actor.

Que se asocia con una categoría de

usuario u otro elemento de interacción.
Diagramas de
Caso de Uso Los casos de uso se muestran como
óvalos.

Los actores se conectan mediante líneas a

los casos de uso que realizan.

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 9

 • Los casos de uso se colocan en un rectángulo, pero los
actores no.
• Este rectángulo es un recordatorio visual de las fronteras
del sistema y de que los actores están afuera del sistema.
Diagramas de • Algunos casos de uso en un sistema pueden relacionarse
Caso de Uso mutuamente.
• Para evitar duplicación en casos de uso, por lo general es
mejor crear un nuevo caso de uso que represente la
actividad duplicada y luego dejar que los otros casos de uso
incluyan este nuevo caso de uso como uno de sus pasos.

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 10

 Diagrama de
Caso de Uso
con Caso de
Uso incluido

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 11

 • Dado que despliega todos los casos de uso,
un diagrama de uso de caso es un auxiliar
útil para asegurar que cubrió toda la
funcionalidad del sistema.
Diagrama de • La contribución más valiosa de casos de uso
Caso de Uso al proceso de desarrollo de software es la
descripción textual de cada caso de uso, no
UML el diagrama de uso de caso global.
• Es a través de las descripciones que usted
puede tener una comprensión clara de las
metas del sistema que desarrolla.

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 12

 ¡Gracias!

Ing. Percy Calizaya, PMP, PSM I, ITIL v4 UNI | FIIS | SI903U 13