✅ Calidad de software

1. ¿Cuántas características de calidad integra el modelo de calidad del PRODUCTO de la norma ISO/IEC 25010:2011?

1. 6 características
2. 7 características
3. 8 características
4. 9 características

El modelo de calidad del producto de ISO/IEC 25010:2011 (SQuaRE) define ocho características: adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad. La revisión ISO/IEC 25010:2023 amplió el modelo a nueve. (ISO/IEC 25010:2011) (ISO/IEC 25010:2011, SQuaRE — System and software quality models)

2. ¿Cuál de las siguientes opciones pertenece al modelo de calidad DEL PRODUCTO de ISO/IEC 25010, y no al modelo de calidad en uso?

1. Efectividad en el uso
2. Satisfacción del usuario
3. Mantenibilidad del producto
4. Cobertura del contexto de uso

Mantenibilidad es una de las ocho características del modelo de calidad del producto; efectividad, satisfacción y cobertura del contexto son características del modelo de calidad en uso. (ISO/IEC 25010:2011, SQuaRE — System and software quality models)

3. ¿Cuántas características integran el modelo de calidad EN USO de la norma ISO/IEC 25010?

1. 4
2. 5
3. 6
4. 8

El modelo de calidad en uso de ISO/IEC 25010 define cinco características: efectividad, eficiencia, satisfacción, ausencia de riesgo y cobertura del contexto, distintas de las ocho del modelo de producto. (ISO/IEC 25010:2011, SQuaRE — System and software quality models)

4. La norma ISO/IEC 9126-1, sustituida posteriormente por ISO/IEC 25010, definía un modelo de calidad del producto con:

1. 5 características, sin incluir seguridad ni compatibilidad
2. 6 características, sin incluir seguridad ni compatibilidad
3. 7 características, incluyendo seguridad pero no compatibilidad
4. 8 características, iguales a las de ISO/IEC 25010

ISO/IEC 9126-1 definía seis características (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad); ISO/IEC 25010 la sustituyó agregando compatibilidad y seguridad como características independientes. (ISO/IEC 9126-1:2001 (sustituida por ISO/IEC 25010:2011))

5. Un equipo de arquitectura evalúa si un sistema puede cambiar de un motor de base de datos a otro distinto con un esfuerzo mínimo de adaptación del código. Según ISO/IEC 25010, esta capacidad corresponde principalmente a:

1. Portabilidad
2. Compatibilidad
3. Mantenibilidad
4. Fiabilidad

La portabilidad, mediante su subcaracterística de adaptabilidad, es la capacidad de un producto de adaptarse eficazmente a diferentes entornos de hardware, software u operación, como cambiar de motor de base de datos; la mantenibilidad se refiere a modificar el propio producto, no a adaptarlo a un entorno distinto. (ISO/IEC 25010:2011, SQuaRE — System and software quality models)

6. Durante una prueba de estrés se mide cuántas transacciones simultáneas soporta un sistema antes de que sus tiempos de respuesta se degraden. Esta medición corresponde a la característica de:

1. Eficiencia de desempeño
2. Fiabilidad del sistema
3. Adecuación funcional
4. Capacidad de interacción

La eficiencia de desempeño evalúa el comportamiento relativo a los recursos usados, como el tiempo de respuesta y la capacidad de proceso, bajo condiciones determinadas. (ISO/IEC 25010:2011, SQuaRE — System and software quality models)

7. Un sistema bancario continúa realizando correctamente sus operaciones críticas de transferencia mientras uno de sus servidores falla de manera inesperada, sin interrumpir el servicio. Esta capacidad corresponde principalmente a la subcaracterística de:

1. Tolerancia a fallos
2. Capacidad de recuperación
3. Disponibilidad del sistema
4. Madurez del producto

La tolerancia a fallos es la capacidad de operar según lo previsto pese a la presencia de fallos de hardware o software, como seguir procesando transacciones cuando un servidor cae. Se distingue de la disponibilidad, que mide si el sistema está operativo y accesible cuando se le requiere, y de la capacidad de recuperación, que restablece datos y estado tras una interrupción. (ISO/IEC 25010:2011, SQuaRE — System and software quality models (subcaracterísticas de fiabilidad))

8. ¿Cuál de las siguientes características NO forma parte de las ocho características del modelo de calidad del PRODUCTO de ISO/IEC 25010?

1. Seguridad
2. Compatibilidad
3. Efectividad
4. Portabilidad

Efectividad pertenece al modelo de calidad EN USO, no al modelo de calidad del producto; seguridad, compatibilidad y portabilidad sí son características del producto. (ISO/IEC 25010:2011, SQuaRE — System and software quality models)

9. Un usuario con discapacidad visual reporta que no puede operar una aplicación móvil porque los botones no son reconocidos por su lector de pantalla. Según ISO/IEC 25010, esta situación afecta principalmente a la característica de:

1. Capacidad de interacción
2. Adecuación funcional
3. Compatibilidad del sistema
4. Fiabilidad del sistema

La capacidad de interacción (usabilidad) incluye la subcaracterística de accesibilidad, es decir, el grado en que el producto puede ser usado por personas con el rango más amplio de características, incluidas discapacidades. (ISO/IEC 25010:2011, SQuaRE — System and software quality models)

10. En ingeniería de software, la verificación responde principalmente a la pregunta:

1. ¿Estamos construyendo el producto correctamente?
2. ¿Estamos construyendo el producto correcto?
3. ¿El producto satisface la necesidad real del negocio?
4. ¿El producto es fácil de aprender a usar?

La verificación evalúa si el producto se construye conforme a las especificaciones establecidas ('building the product right'); la validación evalúa si se construyó el producto correcto frente a las necesidades reales del usuario. (Boehm, B. (1981), Software Engineering Economics; IEEE Std 1012 (Software Verification and Validation))

11. La validación de software se enfoca principalmente en confirmar que:

1. El código cumple con el estándar de codificación acordado
2. El software satisface los requerimientos reales del usuario
3. El diseño es consistente con la arquitectura definida
4. Cada módulo del sistema compila sin errores de sintaxis

La validación responde a si se construyó el producto correcto, es decir, si satisface las necesidades reales del usuario, típicamente mediante pruebas de aceptación sobre el sistema en funcionamiento. (IEEE Std 1012 (Software Verification and Validation); ISO/IEC/IEEE 12207)

12. ¿Cuál de las siguientes actividades es un ejemplo típico de VERIFICACIÓN, y no de validación?

1. Una prueba de aceptación con usuarios finales sobre el sistema terminado
2. Una inspección técnica del documento de diseño contra el requerimiento de origen
3. Una demostración del producto al cliente antes de la entrega final
4. Una encuesta de satisfacción aplicada después del despliegue en producción

Las inspecciones de artefactos intermedios contra su especificación de origen son técnicas de verificación; las pruebas de aceptación y la satisfacción del usuario corresponden a validación. (IEEE Std 1012 (Software Verification and Validation); ISO/IEC/IEEE 12207)

13. Un analista revisa que el código fuente de un módulo que procesa un arreglo de registros de clientes cumpla exactamente con las reglas descritas en el documento de diseño detallado, sin ejecutar el programa. Esta actividad corresponde a:

1. Prueba de aceptación
2. Prueba de regresión
3. Verificación estática
4. Validación dinámica

Revisar un artefacto contra su especificación sin ejecutar el software es una técnica de verificación estática; no implica ejecución ni confrontación con el usuario final, como sí ocurre en la validación. (IEEE Std 1012 (Software Verification and Validation))

14. Un requerimiento indica que el sistema debe permitir cancelar un pedido en cualquier momento antes del envío. El equipo implementa la función exactamente como se especificó, y todas las pruebas contra esa especificación pasan. Al entregar el sistema, los usuarios señalan que en realidad necesitaban poder cancelar también pedidos ya enviados pero no entregados. Este caso ilustra que el producto:

1. Fue verificado correctamente, pero no validado correctamente
2. Fue validado correctamente, pero no verificado correctamente
3. No fue verificado correctamente ni validado correctamente
4. Fue verificado y validado correctamente en su totalidad

El sistema cumple fielmente la especificación documentada (verificación exitosa), pero no satisface la necesidad real del usuario (validación fallida), lo que ilustra la diferencia entre construir el producto correctamente y construir el producto correcto. (Boehm, B. (1981), Software Engineering Economics; IEEE Std 1012)

15. ¿En qué momento del ciclo de vida es más apropiado aplicar las técnicas de verificación, conforme a su definición estándar?

1. Al final del proyecto, sobre el producto ya integrado y terminado
2. Durante cada fase de desarrollo, contra las condiciones definidas al inicio de esa fase
3. Durante la fase de mantenimiento, después de la liberación a producción
4. Después de la firma de aceptación del cliente, como control de cierre

La verificación se aplica en cada fase del desarrollo para confirmar que los productos de trabajo cumplen las condiciones impuestas al inicio de esa fase; la validación, en cambio, suele centrarse en el producto final frente a las necesidades del usuario. (IEEE Std 1012 (Software Verification and Validation))

16. ¿Cuál de las siguientes es una técnica característica de la VALIDACIÓN de software?

1. Revisión formal por pares del código fuente
2. Inspección del documento de requerimientos
3. Auditoría del cumplimiento del estándar de codificación
4. Prueba de aceptación del sistema en funcionamiento

La prueba de aceptación, al ejecutarse sobre el sistema en funcionamiento y confrontarlo con las necesidades reales del usuario, es una técnica típica de validación; las demás opciones son técnicas de verificación estática. (IEEE Std 1012 (Software Verification and Validation))

17. ¿Cuál de las siguientes listas corresponde correctamente a los cinco tipos de función que distingue el conteo de Puntos de Función de IFPUG?

1. Entradas externas, salidas externas, consultas externas, archivos lógicos internos y archivos de interfaz externa
2. Entradas externas, salidas externas, consultas externas, archivos lógicos internos y bases de datos externas
3. Entradas externas, salidas externas, interfaces de usuario, archivos lógicos internos y archivos de interfaz externa
4. Entradas externas, procesos internos, consultas externas, archivos lógicos internos y archivos de interfaz externa

IFPUG clasifica la funcionalidad en cinco tipos: Entradas Externas (EI), Salidas Externas (EO), Consultas Externas (EQ), Archivos Lógicos Internos (ILF) y Archivos de Interfaz Externa (EIF); términos como 'bases de datos externas' o 'interfaces de usuario' no forman parte de esta clasificación. (ISO/IEC 20926; IFPUG Function Point Counting Practices Manual)

18. En el conteo de puntos de función IFPUG, ¿qué distingue a un Archivo Lógico Interno (ILF) de un Archivo de Interfaz Externa (EIF)?

1. El ILF es mantenido dentro de la aplicación contada; el EIF es mantenido por otra aplicación
2. El ILF representa una consulta de datos; el EIF representa una entrada de datos
3. El ILF aplica solo a bases relacionales; el EIF aplica solo a archivos planos
4. El ILF se pondera con mayor complejidad; el EIF se pondera con menor complejidad

Un ILF es un grupo de datos lógicamente relacionado que es mantenido dentro de la aplicación contada; un EIF es un grupo de datos referenciado por la aplicación, pero mantenido por otra aplicación. (IFPUG Function Point Counting Practices Manual; ISO/IEC 20926)

19. El Factor de Ajuste de Valor (VAF) de IFPUG se calcula con la fórmula VAF = 0.65 + 0.01 × Σ(GSC), donde Σ(GSC) es la suma de las calificaciones (0 a 5) de 14 características generales del sistema. Si esa suma es 40, ¿cuál es el valor del VAF?

1. 0.65
2. 1.05
3. 1.35
4. 0.40

VAF = 0.65 + 0.01 × 40 = 0.65 + 0.40 = 1.05; confundirlo con el valor base (0.65) o con el máximo posible (1.35) son errores comunes. (IFPUG Function Point Counting Practices Manual)

20. Un sistema tiene 250 Puntos de Función No Ajustados (UFP) y un Factor de Ajuste de Valor (VAF) de 1.10. Aplicando FP = UFP × VAF, ¿cuántos Puntos de Función ajustados tiene el sistema?

1. 227 puntos de función
2. 250 puntos de función
3. 251 puntos de función
4. 275 puntos de función

FP = UFP × VAF = 250 × 1.10 = 275; dividir en lugar de multiplicar (227) o ignorar el ajuste (250) son errores típicos de cálculo. (IFPUG Function Point Counting Practices Manual; ISO/IEC 20926)

21. Un módulo de 8,000 líneas de código (8 KLOC) presenta 24 defectos detectados durante las pruebas. Calculando la densidad de defectos como defectos entre tamaño, ¿cuál es su valor?

1. 0.33 defectos por KLOC
2. 3 defectos por KLOC
3. 24 defectos por KLOC
4. 192 defectos por KLOC

Densidad de defectos = 24 defectos / 8 KLOC = 3 defectos por KLOC; invertir la razón (0.33) o multiplicar en vez de dividir (192) son errores frecuentes. (ISO/IEC 25023:2016; IEEE Std 982.1)

22. La densidad de defectos es una métrica de producto que relaciona el número de defectos encontrados con:

1. El número de programadores que participaron en el proyecto
2. El tamaño del software, expresado en KLOC o en puntos de función
3. El número de horas dedicadas a las actividades de prueba
4. El presupuesto total asignado a la fase de pruebas

La densidad de defectos se define como el cociente entre el número de defectos y el tamaño del software, medido comúnmente en miles de líneas de código (KLOC) o en puntos de función. (ISO/IEC 25023:2016; IEEE Std 982.1)

23. Dos módulos de un mismo sistema presentan 15 defectos detectados cada uno durante las pruebas. El módulo A tiene 5,000 líneas de código y el módulo B tiene 15,000 líneas de código. Desde el punto de vista de la densidad de defectos, ¿qué puede concluirse?

1. Ambos módulos tienen la misma densidad de defectos
2. El módulo B tiene mayor densidad de defectos que el módulo A
3. El módulo A tiene mayor densidad de defectos que el módulo B
4. La densidad de defectos no puede calcularse sin más datos

La densidad del módulo A es 15/5 = 3 defectos por KLOC y la del módulo B es 15/15 = 1 defecto por KLOC; aunque el número absoluto de defectos es igual, el módulo A concentra más defectos por unidad de tamaño. (ISO/IEC 25023:2016; IEEE Std 982.1)

24. La versión 1 de un producto tuvo 40 defectos en 500 puntos de función, y la versión 2 tuvo 30 defectos en 250 puntos de función. ¿Qué versión presenta mejor calidad según la densidad de defectos, y con qué valor?

1. La versión 2, con 0.08 defectos por punto de función
2. La versión 1, con 0.12 defectos por punto de función
3. La versión 1, con 0.08 defectos por punto de función
4. La versión 2, con 0.12 defectos por punto de función

Densidad v1 = 40/500 = 0.08 defectos por punto de función; densidad v2 = 30/250 = 0.12; una menor densidad indica mejor calidad, por lo que la versión 1 es superior. (ISO/IEC 25023:2016; IFPUG Function Point Counting Practices Manual)

25. Respecto al Factor de Ajuste de Valor (VAF) del conteo de puntos de función IFPUG, ¿cuál de las siguientes afirmaciones es correcta?

1. Sustituye por completo el conteo de los puntos de función no ajustados
2. Se calcula a partir de las cinco categorías de funciones (EI, EO, EQ, ILF, EIF)
3. Su valor puede oscilar entre 0 y 2, según la complejidad del sistema
4. Se calcula a partir de 14 características generales del sistema, calificadas de 0 a 5

El VAF se obtiene sumando la calificación (0 a 5) de 14 características generales del sistema y aplicando VAF = 0.65 + 0.01×Σ(GSC), con un rango válido de 0.65 a 1.35. (IFPUG Function Point Counting Practices Manual; ISO/IEC 20926)

26. ¿Cuál es el propósito principal de la norma ISO/IEC/IEEE 12207 dentro de la ingeniería de software?

1. Especificar los niveles de madurez organizacional que una empresa de desarrollo debe alcanzar.
2. Establecer el procedimiento de evaluación de la calidad de un producto de software ya construido.
3. Establecer un marco común de procesos para todo el ciclo de vida del software, desde la adquisición hasta el retiro.
4. Definir las características y subcaracterísticas de calidad que debe cumplir el producto de software terminado.

ISO/IEC/IEEE 12207 es la norma de referencia de procesos del ciclo de vida del software (adquisición, suministro, desarrollo, operación, mantenimiento, soporte); no define características de producto (eso corresponde a ISO/IEC 25010) ni niveles de madurez (eso corresponde a CMMI). (ISO/IEC/IEEE 12207:2017, Systems and software engineering — Software life cycle processes.)

27. En la estructura de procesos de ISO/IEC/IEEE 12207:2017, armonizada con ISO/IEC/IEEE 15288:2015, el proceso de Aseguramiento de la Calidad se ubica dentro de:

1. los procesos de soporte del software (Software Support Processes).
2. los procesos de acuerdo (Agreement Processes).
3. los procesos técnicos de gestión (Technical Management Processes).
4. los procesos de reutilización del software (Software Reuse Processes).

En la edición 2017, armonizada con ISO/IEC/IEEE 15288:2015, el Aseguramiento de la Calidad es un proceso técnico de gestión, junto con Gestión de la Configuración, Medición y Gestión de Riesgos. La agrupación 'Procesos de Soporte del Software' correspondía a la edición 2008, no a la estructura de 2017. (ISO/IEC/IEEE 12207:2017, Technical Management Processes (Quality Assurance); alineación con ISO/IEC/IEEE 15288:2015.)

28. En la estructura clásica de ISO/IEC 12207 (procesos primarios, de soporte y organizacionales), los procesos de Adquisición, Suministro, Desarrollo, Operación y Mantenimiento se clasifican como:

1. procesos de soporte del ciclo de vida.
2. procesos organizacionales del ciclo de vida.
3. procesos de reutilización del ciclo de vida.
4. procesos primarios del ciclo de vida.

Estos cinco procesos constituyen los procesos primarios, orientados a que una parte obtenga o entregue un producto de software; verificación, validación y auditoría, entre otros, son procesos de soporte. (ISO/IEC 12207:1995/2008, categoría de procesos primarios del ciclo de vida.)

29. De los siguientes procesos definidos en ISO/IEC 12207 (edición 1995/2008), ¿cuál pertenece a la categoría de procesos organizacionales del ciclo de vida?

1. Gestión de la configuración de software.
2. Mejora del proceso.
3. Revisión conjunta.
4. Validación de software.

Mejora, junto con Gestión, Infraestructura y Capacitación, forma parte de los procesos organizacionales; gestión de configuración, revisión conjunta y validación son procesos de soporte. (ISO/IEC 12207:1995/2008, categoría de procesos organizacionales del ciclo de vida.)

30. Un equipo entrega un módulo de facturación que cumple exactamente con los requerimientos especificados en el documento de diseño, pero al probarlo con los usuarios finales estos señalan que no resuelve su necesidad real de conciliación de pagos. ¿Qué proceso de ISO/IEC/IEEE 12207 se encarga de confirmar que el software satisface el uso previsto por el usuario, más allá de los requerimientos documentados?

1. Validación de software.
2. Verificación de software.
3. Auditoría de software.
4. Gestión de configuración de software.

La validación confirma que el producto satisface las necesidades para su uso previsto ("construir el producto correcto"); la verificación solo confirma el cumplimiento de los requerimientos especificados. (ISO/IEC/IEEE 12207:2017, procesos de Validación de software y de Verificación de software.)

31. Un ingeniero de software compara el diseño detallado de un componente contra los requerimientos especificados en la etapa previa, para confirmar que el diseño los refleja correctamente antes de pasar a la construcción. ¿Qué proceso de ISO/IEC/IEEE 12207 describe mejor esta actividad?

1. Validación de software.
2. Aseguramiento de la calidad del software.
3. Verificación de software.
4. Auditoría de software.

La verificación confirma que un producto de trabajo refleja correctamente los requerimientos especificados de la etapa anterior ("construir el producto correctamente"), a diferencia de la validación, orientada al uso previsto. (ISO/IEC/IEEE 12207:2017, proceso de Verificación de software.)

32. La edición 2017 de ISO/IEC/IEEE 12207 armonizó su estructura de procesos de ciclo de vida del software con la de otra norma conjunta ISO/IEC/IEEE. ¿Con cuál?

1. ISO/IEC 20926 (medición funcional IFPUG).
2. ISO/IEC 33020 (marco de medición de capacidad de procesos).
3. ISO/IEC 25040 (proceso de evaluación de la calidad del producto).
4. ISO/IEC/IEEE 15288 (procesos del ciclo de vida de sistemas).

Las ediciones 2017 de 12207 (software) y 15288 (sistemas) comparten una estructura común de procesos de ciclo de vida, facilitando su uso conjunto en proyectos de sistemas con componentes de software. (ISO/IEC/IEEE 12207:2017, introducción y relación con ISO/IEC/IEEE 15288:2015.)

33. Respecto a los modelos de desarrollo de software (cascada, iterativo, ágil, entre otros), ¿qué característica distingue a ISO/IEC/IEEE 12207 como norma de procesos?

1. Requiere que la organización adopte el modelo en cascada en todos sus proyectos.
2. Es independiente del modelo o metodología de ciclo de vida que la organización decida adoptar.
3. Requiere que la organización adopte una metodología ágil certificada en todos sus proyectos.
4. Requiere que la organización combine el modelo en espiral con prototipos en todos sus proyectos.

12207 define qué procesos deben existir y su propósito, sin prescribir un modelo de ciclo de vida ni una metodología específica para ejecutarlos. (ISO/IEC/IEEE 12207:2017, alcance y naturaleza de norma de referencia de procesos.)

34. ¿Cuál de los siguientes procesos NO pertenece a los procesos de soporte del ciclo de vida definidos en ISO/IEC 12207 (edición 1995/2008)?

1. Suministro.
2. Gestión de la configuración de software.
3. Auditoría de software.
4. Resolución de problemas de software.

Suministro es un proceso primario en la edición 1995/2008, mientras que gestión de la configuración, auditoría y resolución de problemas son procesos de soporte del ciclo de vida. (ISO/IEC 12207:1995/2008, categorías de procesos primarios y de soporte.)

35. ¿Quién desarrolló, en 1976 durante su trabajo en IBM, el método formal de revisión de software conocido posteriormente como "inspección Fagan"?

1. Watts Humphrey.
2. Barry Boehm.
3. Michael Fagan.
4. Tom DeMarco.

Michael Fagan formalizó en IBM el proceso de inspección de software con roles y fases definidas; Humphrey es conocido por PSP/TSP y Boehm por COCOMO y el modelo espiral. (Fagan, M. E. (1976), 'Design and Code Inspections to Reduce Errors in Program Development', IBM Systems Journal.)