MODELOS Y ATRIBUTOS DE CALIDAD DEL SOFTWARE

Modelo de McCall
Perspectivas
Operación: la forma en
que el software lleva a
cabo sus funcionalidades, y
la medida en la cual
cumple con sus
especificaciones.
Revisión: capacidad del
software para adaptarse a
los cambios.
Transición: capacidad del
software para adaptarse a
distintos contextos de
operación.
Factores de calidad
Integridad (protección contra accesos no autorizados a la
información)
Corrección (que las funcionalidades solicitadas en su especificación
se encuentren disponibles)
Fiabilidad (qué fallos tiene el sistema en operación)
Usabilidad
Eficiencia (en términos de uso de recursos)
Facilidad de mantenimiento (disposición para ser modificado, para
ser corregido, adaptado o ampliado)
Facilidad de evaluación o prueba (capacidad de validar los requisitos
establecidos para el software)
Flexibilidad (capacidad para introducir cambios en función de las
necesidades de negocio)
Portabilidad
Interoperabilidad
Reusabilidad

Modelo ISO 9126

Atributo de calidad Sub clasificación
Funcionalidad Precisión (exactitud)
Seguridad de acceso
Interoperabilidad
Idoneidad (adecuación)
Conformidad
Fiabilidad Madurez
Tolerancia a fallos
Capacidad de recuperación
Usabilidad Comprensibilidad (capacidad de ser entendido)
Facilidad de aprendizaje
Operabilidad (capacidad de operarlo y controlarlo)
Atracción
Eficiencia Comportamiento temporal (tiempos de respuesta y procesamiento)
Utilización de recursos
Mantenibilidad Facilidad de prueba (capacidad de validar las partes modificadas)
Analizabilidad (capacidad para diagnosticar defectos y partes a
modificar)
Cambiabilidad (capacidad de implementar una modificación)
Estabilidad (capacidad de evitar efectos inesperados debido a
modificaciones)
Portabilidad Adaptabilidad (capacidad de adaptarse a diferentes entornos)
Facilidad de instalación
Coexistencia (capacidad de coexistir con otro software en un entorno
común)
Remplazabilidad (capacidad para ser usado en lugar de otro)

MCC Ing. Lain Jardiel Cárdenas Escalante. Página 1

 Modelo FURPS+
Atributo de calidad Sub clasificación
Funcionalidad
Usabilidad Accesibilidad
Estética
Consistencia de IU
Ergonomía
Fácil de usar
Confiabilidad Disponibilidad
Robustez
Precisión
Capacidad de recuperación
Tolerancia a fallos
Seguridad
Exactitud
Desempeño Rendimiento
Tiempo de respuesta
Tiempo de recuperación
Tiempo de inicio o cierre
Capacidad
Utilización de recursos
Soportabilidad Capacidad de prueba
Adaptabilidad
Mantenimiento
Compatibilidad
Configurable
Capacidad de actualización
Facilidad de instalación
Escalabilidad
Portabilidad
Reusabilidad
Interoperabilidad
Remplazabilidad
Cambiabilidad
Capacidad de localización
Restricciones de diseño
Requerimientos de implementación
Requerimientos de interfaz
Requerimientos físicos
Requerimientos de documentación
Requerimientos legales y de licencia

MCC Ing. Lain Jardiel Cárdenas Escalante. Página 2

 REQUISITOS DE SOFTWARE

Tipos de requisitos
Establecen los comportamientos del sistema. Definen lo que el sistema
Funcional
debería de hacer.
También llamados requisitos de calidad. Verifican cómo un sistema
No funcional
debería de ser.

Tipo de requisito Caso de Uso Especificaciones Suplementarias

Flujo básico u flujos alternativos Requerimientos funcionales
Funcional relacionados a un caso de uso relacionados a más de un caso de
específico. uso.
Especificación no funcional Requerimientos no funcionales
No funcional relacionada sólo a un caso de relacionados a muchos casos de
uso. uso.

Ejemplos de requisitos no funcionales (requisitos de calidad) según el modelo FURPS+

USABILIDAD:
• Accesibilidad:
o La funcionalidad de reservar un billete de avión estará disponible desde la página
principal.
o La funcionalidad de alquiler de un coche estará disponible después de no más de un
solo clic desde la página de inicio.
• Estética:
o Múltiples campos de entrada en una página se alinean verticalmente.
• Ergonomía:
o Cuando un cuadro de diálogo se abre, el foco estará en el primer campo de entrada
en el cuadro de diálogo.
• Fácil de usar:
o Sin necesidad de conocimientos técnicos se requiere poder utilizar el sistema.
o El usuario deberá ser capaz de aprender a utilizar el sistema en una hora.
o El promedio de tiempo de reservar una habitación de hotel no serán más de diez
minutos.

CONFIABILIDAD:
• Robustez:
o Por cada entrada que no es válida para el usuario, el sistema mostrará un mensaje
de error significativo que explica cuál es el formato de entrada que se espera.
• Precisión:
o Las cantidades de dinero se calculan y se almacenan con una precisión de dos
decimales.
• Seguridad:
o La clave de acceso será necesario para acceder a las pantallas del administrador.

MCC Ing. Lain Jardiel Cárdenas Escalante. Página 3

DESEMPEÑO:
• Rendimiento:
o El sistema deberá adaptarse a 1,000 vuelos reservados por minuto (1,000
transacciones por minuto).
• Tiempo de respuesta:
o El tiempo medio de respuesta del sistema debe ser menos de dos segundos.
o El tiempo medio de retornar una lista de vuelos no será mayor de diez segundos.
• Capacidad:
o El sistema deberá adaptarse a 5,000 usuarios concurrentes.
• Utilización de recursos:
o El sistema deberá almacenar en la base de datos no más de un millón de
transacciones. Si la base de datos crece a lo largo de este límite, las transacciones
viejas deberán ser respaldados y eliminados de la base de datos operacional.

SOPORTABILIDAD:
• Capacidad de prueba:
o La interfaz de usuario no contiene ningún componente que impida las pruebas
automatizadas con IBM Rational Robot e IBM Rational Functional Tester.
• Portabilidad:
o Cambiando la base de datos del sistema en el futuro no será necesario volver a
escribir la lógica de la aplicación.
• Reusabilidad:
o La funcionalidad principal del sistema (la reserva del vuelo, la compra de un billete
de avión, reservar una habitación de hotel, reservar un coche) deberá ser
encapsulada en componentes que pueden ser reutilizados en una aplicación cliente /
servidor (no por Internet).
• Interoperabilidad:
o El sistema automáticamente reservará un billete con el Sistema de Reservas de
Línea Aérea sin necesidad de intervención humana.

Referencia bibliográfica:

Peter Zielczynski, Ph.D. Requirements Management Using IBM Rational RequisitePro. IBM Press, 2008.

MCC Ing. Lain Jardiel Cárdenas Escalante. Página 4