UNIVERSIDAD POLITÉCNICA DE QUINTANA ROO

PLANTEL: CANCÚN, Q. ROO

ESCENARIOS, INFORMACIÓN Y CLASE DE ANÁLISIS DE SOFTWARE

ALUMNO: MARTIN MARTINEZ ARIAS

2DO. CUATRIMESTRE

MATERIA: INGENIERIA DE REQUERIMIENTOS DE SOFTWARE

GPO. 22-AM ING. EN SOFTWARE

DOCENTE: LIC. MOISÉS ORTEGA ZETINA

ENTREGA: 08/06/2022

CANCUN, QUINTANA ROO

1
 METRICAS DEL SOFTWARE

Definición del concepto escenario de software:

▪ Un escenario es una descripción parcial del comportamiento de la aplicación en un
momento específico. La utilización de escenarios implica identificar distintas situaciones
y describir la acción a llevar a cabo.
En los escenarios por lo general las personas encuentran más sencillo vincularse ejemplos reales
que con descripciones abstractas, estas se puedan comprender y criticar sobre cómo interactuar
con un sistema de software.
Un escenario comienza con un bosquejo de la interacción durante el proceso de adquisición se
suma detalles a este para crear una representación completa de dicha interacción.
En su forma más general, un escenario puede incluir:
1. Una descripción sobre lo que se espera del sistema y los usuarios cuando inicia el
escenario.
2. Una descripción en el escenario de flujo normal de los eventos.
3. Una descripción de qué puede salir mal y cómo se manejaría.
4. Información de otras actividades que están en marcha al mismo tiempo.
5. Una descripción del estado del sistema cuando termina el escenario.
Otras de las cosas que deben incluirse en los escenarios son: la suposición inicial, normal, otras
actividades y el estado del sistema a completar. (Medina, 2016).

Casos
Los casos son una técnica de descubrimiento de requerimientos que se introdujo por primera vez
en 1993 por Ivar Jacobson.
A día de hoy se ha convertido en una característica fundamental del modelado del lenguaje
unificado; en su forma más sencilla, un caso de uso identifica los actores implicados en una
interacción y nombra el tipo de interacción, entonces esta se complementa con una información
adicional al que describe la interacción con el sistema, la información adicional puede ser una
descripción textual o bien una o más modelos gráficos como secuencia UML o un gráfico de
estado.
No hay distinción tajante y rápida entre escenarios y casos de uso, algunas personas consideran
que cada caso de uso es un solo escenario, otras como sugieren encapsular en un conjunto de
escenarios en un solo caso de uso.
Cada escenario es un solo hilo a través del caso de uso por lo tanto habría un escenario para la
forma de interacción normal, más escenarios para cada posible excepción, en la práctica es
posible usarlos en cualquier forma.
Los escenarios y los casos de uso son técnicas efectivas para adquirir requerimientos de los
participantes que interactúan directamente con el sistema, cada tipo de interacción puede
representarse como caso de uso, sin embargo, debido a que se enfoca en interacciones del
sistema no son tan efectivas para adquirir requerimientos empresariales si no funcionan como
alto nivel, ni para descubrir requerimientos de dominio.

2
 METRICAS DEL SOFTWARE

Origen
En 1986 Ivar Jacobson, importante contribuyente al desarrollo de los modelos UML y proceso
unificado, creó el concepto de caso de uso.
Ahora se han realizado muchas mejoras del concepto que se estableció entonces, pero
probablemente la más influyente y significativa en términos de definición del término caso de uso
fue la de Alistair Cockburn con el libro de escribir casos de uso efectivos publicado en el año
2000.
Durante los años 1990 los casos de uso se convirtieron en una de las prácticas más comunes de
la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la
programación orientada a objetos donde se originaron, si bien pueden utilizarse con resultados
igualmente satisfactorios con otros paradigmas de programación.
Ventajas
Algunas de las ventajas de estos dos casos es que son fácil de comprender y criticar en un
escenario, describe el estado inicial del escenario, describe el flujo de eventos, descubre
excepciones y soluciones y descubre cómo llevar a cabo situaciones paralelas.
Desventajas
En sistemas grandes toma mucho tiempo definir todos los casos de uso, el análisis de la calidad
depende de la calidad con la que se haya hecho la descripción inicial, toman tiempo de acuerdo
a la complejidad del sistema y las personas que modelan el sistema deben conocerlo
previamente.
Conclusiones
Como se ha visto en este documento los escenarios, información y clase de análisis en la
ingeniería de software son muy importantes por los siguientes aspectos.
Primeramente, nosotros como ingenieros necesitamos recopilar información de los
clientes/usuarios (cualquier tipo), para que con la información que no proporcionen podamos
extraer los requisitos del sistema que ellos esperan.
Segundo una vez con toda la información proporcionada por el usuario y con los requisitos ya
analizados nosotros como ingenieros debemos mostrarle los escenarios del sistema que se
estará desarrollando y con escenarios me refiero a las ventajas y las desventajas del sistema
que se estará desarrollando.
Tercero una vez ya habiendo analizado los escenarios junto con los clientes nosotros como
ingenieros debemos diseñar los casos de uso que esto a su vez van de la mano con los
escenarios.

3
 METRICAS DEL SOFTWARE

Bibliografía
Medina, A. B. (08 de 11 de 2016). youtube.com. Obtenido de YouTube:
https://www.youtube.com/watch?v=oxDy5OP48OA&t=63s

Osuna, P. (2016). slideplayer.es. Obtenido de SlidePlayer: https://slideplayer.es/slide/1552855/

Ruvalcaba, M. (19 de 03 de 2022). sg.com.mx. Obtenido de SG: https://sg.com.mx/revista/1/procesos-

software