Docente: Lain Jardiel Cárdenas Escalante

Saberes previos

Responder cuestionario en BlackBoard

 Realidad problemática
La Fábrica de Software a cargo del proyecto MarketSoft, luego de modelar los procesos de negocio,
debe describir los requisitos funcionales y de atributos de calidad para poder diseñar la arquitectura
del Sistema de Información. Pero, la definición no precisa de los requisitos por parte de los usuarios, la
poca disponibilidad de tiempo de los usuarios para validar los requisitos, la mala comunicación de los
usuarios con el equipo de desarrollo y el mal uso de técnicas de especificación, dificultan la
descripción correcta de los requisitos.
Entonces, si no se capturan y especifican adecuadamente los requisitos, se corre un alto riesgo en
tomar malas decisiones de diseño arquitectónico y tendríamos un sistema que no cumple con los
atributos de calidad esperados, así como generar en el futuro muchos problemas de soporte o
mantenimiento del sistema.
Por tanto, para dar solución al problema anterior, la Fábrica de Software debe planificar y realizar
actividades para especificar los requisitos de los atributos de calidad con las técnicas adecuadas.

Por Lain Cárdenas

 Conflicto cognitivo

¿Cómo describir los atributos de calidad que

queremos que nuestra arquitectura aporte al
sistema que estamos construyendo?
 Logro
Al término de la sesión, el estudiante
desarrolla una práctica sobre requisitos de
atributos de calidad, describiendo
escenarios, de forma correcta y respetando
el tiempo establecido.
SESIÓN 2: COMPRENDER LOS ATRIBUTOS DE CALIDAD

• Categoría de requisitos.
• Mapa conceptual lo de los requisitos
• Atributos de calidad.
• Especificación de los requisitos de atributos de
calidad.
• Atributo de calidad: Rendimiento.
• Atributo de calidad: Modificabilidad.
• Atributo de calidad: Interoperabilidad.
 Categoría de requisitos
Requisitos funcionales
• Estos requisitos establecen qué debe hacer el sistema y cómo debe comportarse o
reaccionar ante los estímulos en tiempo de ejecución.

Requisitos de atributos de calidad

• Estos requisitos son calificaciones de los requisitos funcionales o del producto en
general. La cualificación de un requisito funcional es un elemento como la rapidez
con la que se debe realizar la función. Una cualificación del producto global es un
elemento como el tiempo de despliegue del producto.

Restricciones
• Una restricción es una decisión de diseño con cero grados de libertad. Es decir, es
una decisión de diseño que ya se ha tomado. Por ejemplo, el requisito de utilizar
un determinado lenguaje de programación o de reutilizar un determinado módulo
existente, o una orden de la dirección para que el sistema esté orientado a servicio.
¿Cuál es la "respuesta" de la arquitectura a cada uno de estos
tipos de requisitos?

Requisitos funcionales
• Se satisfacen asignando una secuencia adecuada de responsabilidades a
lo largo del diseño.

Requisitos de atributos de calidad

• Se satisfacen mediante las diversas estructuras definidas en la
arquitectura, y los comportamientos e interacciones de los elementos
que pueblan esas estructuras.

Restricciones
• Se satisfacen aceptando la decisión de diseño y conciliándola con otras
decisiones de diseño afectadas.
Por Lain Cárdenas
 Atributos de calidad

Modificabilidad Seguridad Usabilidad

Rendimiento Interoperabilidad Comprobabilidad

Disponibilidad
 Caso: Guía Turística

Una empresa, que ofrece servicios de guía turística, está interesado en que se
desarrolle un software para dar soporte a sus actividades.
El software, entre las principales cosas que debe hacer son: reservar un vuelo,
comprar un billete de avión, buscar atracciones turísticas, reservar una habitación
de hotel y reservar un auto. Por otra parte, la opción de reservar un vuelo debe estar
accesible desde la página principal. Además, las respuestas a las consultas deben ser
muy rápidas. Por último, el equipo de desarrollo debe poder realizar un fácil
mantenimiento a funciones del sistema en el tiempo.
 Caso: Guía Turística

En base a la descripción de caso de Guía Turística, se obtienen los siguientes requisitos según su
categoría.

Categoría Descripción de los requisitos Observación

Reservar un vuelo, comprar un billete de avión, buscar
Descripción muy
Funcional atracciones turísticas, reservar una habitación de hotel y
general.
reservar un auto.
La opción de reservar un vuelo debe estar accesible desde la Descripción con
Usabilidad
página principal. cierta precisión.
Descripción no
Rendimiento Las respuestas a las consultas deben ser muy rápidas.
precisa ni medible.
El equipo de desarrollo debe poder realizar un fácil Descripción no
Modificabilidad
mantenimiento a funciones del sistema en el tiempo. precisa ni medible.
 Especificación de los requisitos de atributos de calidad

Un requisito de atributo de calidad debe ser inequívoco y comprobable. Utilizamos una forma
común para especificar todos los requisitos de atributos de calidad: los escenarios de atributos de
calidad.

Esquema la de estructura de un escenario de atributo de calidad

 Estructura de un escenario de atributo de calidad

Origen del Este es alguna entidad (un ser humano, un sistema informático, o cualquier otro
estímulo actuador) que generó el estímulo.
Estímulo El estímulo es una condición o evento que requiere una respuesta cuando este llega a un
sistema. Es la acción que se quiere llevar a cabo.
Entorno El entorno de un requisito es el conjunto de circunstancias en las que tiene lugar el
escenario.
Artefacto El artefacto es la parte del sistema al que se aplica el requisito. Este puede ser una
colección de sistemas, todo el sistema, o alguna pieza o piezas de la misma.
Respuesta La respuesta es la actividad que brinda un resultado cuando llega un estímulo.
Medida de Cuando se produce la respuesta, debe ser medible de alguna manera para que el
respuesta requisito pueda ser probado.
Proyecto MarketSoft
 Requisitos funcionales: Casos de Uso

ID CASOS DE USO
CU1 Procesar Venta
CU2 Generar reporte de ventas mensuales
CU3 Generar reporte de ventas diarias por comprobante
CU4 Generar reporte de ventas diarias por producto
CU5 Gestionar productos
CU6 Gestionar clientes
CU7 Iniciar sesión
Diagrama de Casos de Uso
 Atributo de calidad: Rendimiento

Se trata del tiempo y de la capacidad del sistema de software para cumplir los requisitos de tiempo.
Caracterizar los eventos que pueden ocurrir (y cuándo pueden ocurrir) y la respuesta temporal del
sistema o elemento a esos eventos es la esencia de discutir el rendimiento.
Todos los sistemas tienen requisitos de rendimiento, incluso si no están expresados. Por ejemplo, es
posible que una herramienta de procesamiento de texto no tenga ningún requisito de rendimiento
explícito, pero sin duda todos estarían de acuerdo en que esperar una hora (o un minuto o un
segundo) antes de ver aparecer un carácter escrito en la pantalla es inaceptable. El rendimiento
sigue siendo un atributo de calidad fundamentalmente importante para todo el software.
El rendimiento suele estar relacionado con la escalabilidad, es decir, con el aumento de la capacidad
de trabajo de tu sistema, sin dejar de tener un buen rendimiento.
 Escenario de rendimiento

“Un usuario realiza una consulta al catalogo de productos en un momento normal de operación del
sistema. El sistema muestra el resultado de la consulta en un tiempo no mayor a tres segundos”.

Origen del estímulo Un usuario.

Estímulo Consulta al catalogo de productos.
Entorno Momento normal de operación.
Artefacto El sistema.
Respuesta El sistema muestra el resultado de la consulta.
Medida de respuesta Tiempo no mayor a tres segundos.
 Atributo de calidad: Modificabilidad
Los cambios se producen para añadir nuevas características, para cambiar o incluso para retirar las
antiguas. Los cambios se producen para corregir defectos, reforzar la seguridad o mejorar el
rendimiento. Los cambios se producen para mejorar la experiencia del usuario. Los cambios se
producen para adoptar nuevas tecnologías, nuevas plataformas, nuevos protocolos, nuevos
estándares. Los cambios se producen para que los sistemas funcionen juntos, aunque nunca hayan
sido diseñados para ello.
La modificabilidad tiene que ver con el cambio, y el interés se centra en el coste y el riesgo de hacer
cambios. Para planificar la modificabilidad, un arquitecto debe tener en cuenta cuatro cuestiones:
• ¿Qué puede cambiar?
• ¿Cuál es la probabilidad del cambio?
• ¿Cuándo se hace el cambio y quién lo hace?
• ¿Cuál es el coste del cambio?
 Escenario de modificabilidad

“El desarrollador desea cambiar la interfaz de usuario modificando el código en tiempo de diseño.
Las modificaciones se realizan sin efectos secundarios en tres horas”.

Origen del estímulo El desarrollador.

Estímulo Cambiar la interfaz de usuario.
Entorno En tiempo de diseño.
Artefacto El código.
Respuesta Las modificaciones se realizan sin efectos secundarios.
Medida de respuesta Tres horas.
 Atributo de calidad: Interoperabilidad
La interoperabilidad se refiere al grado en que dos o más sistemas pueden intercambiar información
útil a través de interfaces en un contexto determinado. La definición incluye no sólo la capacidad de
intercambiar datos (interoperabilidad sintáctica), sino también la capacidad de interpretar
correctamente los datos intercambiados (interoperabilidad semántica).

Estas son algunas de las razones por las que puede querer que los sistemas interoperen:
• Tu sistema proporciona un servicio que va a ser utilizado por un conjunto de sistemas
desconocidos.
• Usted está construyendo capacidades a partir de sistemas existentes.

Se destacan dos aspectos importantes de la interoperabilidad:

• Descubrimiento. El consumidor de un servicio debe descubrir la ubicación, la identidad y la
interfaz del servicio.
• Tratamiento de la respuesta. Existen tres posibilidades distintas: el servicio informa al solicitante
con la respuesta, el servicio envía su respuesta a otro sistema o el servicio transmite su respuesta
a cualquier parte interesada.
 Escenario de interoperabilidad

“Nuestro sistema de venta móvil envía una solicitud de pedido al sistema centralizado de control de
ventas, estos sistemas se conocen antes de la ejecución. El sistema centralizado de control de
ventas valida y registra el pedido para su posterior despacho. La solicitud de pedido es procesado
correctamente en un 100%.

Origen del estímulo Sistema de venta móvil.

Estímulo Solicitud de pedido.
Entorno Sistemas conocidos antes de la ejecución.
Artefacto Sistema centralizado de control de ventas.
Respuesta El sistema centralizado de control de ventas valida y registra el pedido.
Medida de respuesta La solicitud de pedido es procesado correctamente en un 100%
 Trabajo en equipo

Desarrolla las actividades propuestas durante la sesión con tu equipo de trabajo.

Preguntas de metacognición

1. ¿Qué aprendí?
2. ¿Cómo lo aprendí?
3. ¿Para qué me sirve lo que aprendí?
4. ¿Cómo hemos distribuido las tareas?
5. ¿Qué dificultades tuve al realizar las tareas?
6. ¿Cómo me sentí en el proceso?
 Bibliografía
❖ Len Bass, Paul Clements, Rick Kazman. (2013). Software Architecture in
Practice. Tercera Ed. Addison Wesley.
✓ Capitulo 4 - Comprender los atributos de calidad.
✓ Capitulo 6 - Interoperabilidad.
✓ Capitulo 7 - Modificabilidad.
✓ Capitulo 8 - Rendimiento.

❖ Craig Larman, (2003) “UML Y PATRONES una Introducción al Análisis y

Diseño Orientado a Objetos y al Proceso Unificado”, 2da edición.
✓ Capitulo 7: Identificación de otros requisitos.