CALIDAD Y PRUEBAS DE SOFTWARE
Docente: Lain Cárdenas Escalante
Motivación
Proyecto MarketSoft
REALIDAD PROBLEMÁTICA
El SuperMarket, para ofrecer un mejor servicio a sus clientes y poder gestionar de forma más
eficiente sus procesos de negocio, ha contratado una fábrica de software para que implemente un
Sistema de Información denominado MarketSoft que apoye sus procesos comerciales,
principalmente el proceso de venta.
La fábrica de software, por experiencia, sabe que va a enfrentar muchas situaciones difíciles como la
poca disponibilidad de tiempo de los usuarios para revisar los requisitos, la comprensión incorrecta
de los requisitos y la mala comunicación entre los usuarios y el equipo. Todo esto, generaría como
resultado una mala definición de los requisitos del software. Como consecuencia, existiría un mal
diseño e implementación del software, un sistema que no hace lo que debería hacer o 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 evitar en lo posible el problema anterior, la fábrica de software debe planificar muy
bien las tareas a realizar y aplicar las técnicas adecuadas que le garanticen una correcta
especificación de los requisitos no funcionales del sistema.
Por Lain Cárdenas
Motivación
¿Cuál es problema central? y
¿Cuáles son las causas?
Saberes previos
Quiz
Conflicto cognitivo
¿Cómo clasificar y especificar los atributos
de calidad para un producto software?
Logro
Al término de la sesión, el estudiante
desarrolla una práctica sobre requisitos
de calidad, aplicando la técnica de
escenarios de atributos de calidad y el
modelo de calidad ISO/IEC 9126, de
forma correcta y respetando el tiempo
establecido.
SESIÓN 2: CALIDAD DEL PRODUCTO Y MODELOS DE
CALIDAD
• Categoría de requisitos.
• El Modelo de calidad de McCall.
• La norma ISO 9126.
• Modelo de calidad ISO/IEC 9126.
• Escenarios de atributos de calidad:
Rendimiento, Modificabilidad e
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.
Por Lain Cárdenas
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.
REPASO
En base a la descripción de caso de Guía turística, describa los
requisitos según su categoría.
CATEGORÍA Descripción del requisito
Funcional
No funcional
(usabilidad)
No funcional
(rendimiento)
No funcional
(modificabilidad)
EL MODELO DE CALIDAD DE MCCALL
Factores de calidad
Criterios de calidad
Métricas de calidad
PERSPECTIVAS DEL MODELO DE MCCALL
Operación del
producto
Calidad
Transición del Revisión del
producto producto
FACTORES DE CALIDAD DEL MODELO DE MCCALL
Perspectivas Factores de calidad Criterios de calidad
Operación Corrección Trazabilidad, compleción
Fiabilidad Consistencia, exactitud, tolerancia a
fallos
Eficiencia En ejecución y en almacenamiento
Integridad Control de acceso, auditoría de acceso
Usabilidad Operabilidad, formación
Revisión Facilidad de Simplicidad, concisión, autodescripción,
mantenimiento modularidad
Facilidad de evaluación Simplicidad, modularidad
Flexibilidad Extencibilidad, generalidad,
modularidad
Transición Portabilidad Independencia de la máquina
Reusabilidad Independencia del sistema software
Interoperabilidad Comunicaciones y datos comunes
LA NORMA ISO 9126
Esta norma propone: (1) Un modelo de calidad, (2) Métricas externas, (3) Métricas
internas, (4) Métricas de calidad en uso.
MODELO DE CALIDAD ISO/IEC 9126
PROYECTO MARKETSOFT
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 ATRIBUTO DE CALIDAD
Requisito 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.
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 ATRIBUTO DE CALIDAD
Requisito 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.
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 ATRIBUTO DE CALIDAD
Requisito 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%
Actividad
Resolver la práctica de laboratorio con su equipo de trabajo durante el tiempo
establecido.
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?
REFERENCIAS BIBLIOGRÁFICAS
✓ Sommerville. (2011) “Ingeniería de Software”, 9na edición.
❑ Capitulo 24: sección [Link] del software.
✓ Sánchez S, Sicilia M, Rodríguez D. (2012). Ingeniería de Software un enfoque desde la guía
SWEBOK. Primera Ed.
❑ Capitulo 9: sección [Link] del producto.
