Quiz
AI07-08
Create a free account to finish this quiz
Save your progress and see your final score.
Already have an account? Sign in
Questions in this quiz (52)
1¿Quién está interesado en evaluar la calidad?
- AOrganismos o empresas que adquieren productos software y organismos o
empresas que externalizan total o parcialmente su proceso de desarrollo software - BFactorías y empresas desarrolladoras de software y organismos o empresas que
externalizan total o parcialmente su proceso de desarrollo software - CFactorías y empresas desarrolladoras de software, organismos o empresas
certificadoras de calidad ambiental y organismos o empresas que externalizan total o parcialmente su proceso de desarrollo software - DFactorías y empresas desarrolladoras de software, organismos o empresas que
adquieren productos software y organismo o empresas que externalizan total o
parcialmente su proceso de desarrollo software
- AOrganismos o empresas que adquieren productos software y organismos o
2Factorías y empresas desarrolladoras de software, ¿están interesadas en evaluar la
calidad de su software?- ANo, porque hoy los clientes compran software basándose exclusivamente en el
precio. - BSi, porque asi venden mas.
- CSí, porque así pueden asegurar a sus clientes que sus productos son de calidad.
- DSí, porque así pueden externalizar sus procesos de desarrollo software con garantía
- ANo, porque hoy los clientes compran software basándose exclusivamente en el
3La deuda técnica hace referencia a:
- AConsecuencias y costes en que incurre una empresa por externalizar software con
debilidades. - BConsecuencia y costes en que incurre una empresa por comprar software con
debilidades. - CConsecuencias y costes en que incurre una empresa por desarrollar software con
debilidades. - DConsecuencias y costes en que incurre una empresa por desarrollar software sin
debilidades.
- AConsecuencias y costes en que incurre una empresa por externalizar software con
4La deuda técnica no intencionada viene dada por:
- ACódigo de baja calidad por un programador junior o asumir un equipo de baja
calidad o adquisición de una empresa con deuda técnica. - BCódigo de baja calidad por un programador junior o adquisición de una empresa con
deuda técnica. - CCódigo de baja calidad por un programador junior, o adquisición de una empresa
con deuda técnica o presión de fechas <<Time to market>>. - DCódigo de baja calidad por un programador junior o asumir un equipo de baja
calidad.
- ACódigo de baja calidad por un programador junior o asumir un equipo de baja
5La deuda técnica intencionada viene dada por:
- ACódigo de baja calidad por un programador junior o asumir un equipo de baja
calidad. - BCódigo de baja calidad por un programador junior o subprocesos de desarrollo de
baja calidad o presión de fechas <<Time to market>> o pruebas y testing pobres. - CSubprocesos de desarrollo de baja calidad o presión de fechas <<Time to market>>
o adquisición de una empresa con deuda técnica. - DSubprocesos de desarrollo de baja calidad o presión de fechas <<Time to market>>
o pruebas y testing pobres.
- ACódigo de baja calidad por un programador junior o asumir un equipo de baja
6La deuda técnica:
- AEs visible y genera valores negativos
- BEs invisible y genera valores negativos
- CEs visible y general valores positivos
- DEs invisible y genera valores positivos
7Las características según el modelo de calidad del producto software recogidas en la
ISO/IEC 9126 son:- AFuncionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad
- BFuncionalidad, fiabilidad, usabilidad, confidencialidad, mantenibilidad y portabilidad
- CFuncionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y trazabilidad
- DRacionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad
8Según el modelo de calidad del producto software de la ISO/IEC 9126 las métricas
internas:- ASon aplicables a la utilización del software por parte de los usuarios.
- BSon aplicables al software en ejecución.
- CNo dependen de la ejecución del software y son, por lo tanto, medidas estáticas.
- DNo dependen de la ejecución del software y son, por tanto, medidas dinámicas
9Según el modelo de calidad del producto software de la ISO/IEC 9126 las métricas
externas:- ASon aplicables a la utilización del software por parte de los usuarios.
- BSon aplicables al software en ejecución
- CNo dependen de la ejecución del software y son, por lo tanto, medidas estáticas.
- DSon aplicables al software en ejecución y la utilización del software por parte de los
usuarios.
10Según el modelo de calidad del producto software de la ISO/IEC 9126 las métricas son:
- ASon aplicables a la utilización del software por parte de los usuarios
- BSon aplicables al software en ejecución.
- CNo dependen de la ejecución de software y son, por lo tanto, medidas estáticas.
- DSon aplicables a la utilización del software por parte de los usuarios y no es
necesario que el software estén en ejecución.
11La ISO/IEC 14598 es un marco de trabajo para:
- AEvaluar la calidad de los procesos de desarrollo software.
- BEvaluar la calidad de los productos de software
- CEvaluar la calidad de los productos de software y de los procesos de desarrollo
software - DDefinir un modelo de calidad del producto software.
12El referente que usara un auditor para evaluar la calidad de un producto software es :
- AISO/IEC 25000.
- BISO/IEC 14598.
- CISO/IEC 15504.
- DISO/IEC 19011.
13En una auditoría de producto software un auditor de AENOR utiliza los siguientes
estándares:- AISO/IEC 19011, ISO/IEC 9126 e ISO/IEC 27001.
- BISO/IEC 15504, ISO/IEC 9126 e ISO/IEC 14598.
- CISO/IEC 19011, ISO/IEC 9000 e ISO/IEC 14598.
- DISO/IEC 19011, ISO/IEC 9126 e ISO/IEC 14598.
14La calidad del producto software se puede interpretar como:
- AEl grado en que dicho producto satisface los requisitos del CEO y CIO aportando de
esta manera un valor. - BEl grado en que dicho producto satisface los requisitos de sus desarrolladores
aportando de esta manera un valor - CEl grado en que dicho producto satisface los requisitos de sus usuarios aportando de
esta manera un valor. - DEl grado en que dicho producto satisface los requisitos de sus usuarios.
- AEl grado en que dicho producto satisface los requisitos del CEO y CIO aportando de
15La ISO/IEC 25000 hereda la característica de calidad de la ISO/IEC 9126 y añade:
- ACompatibilidad y seguridad.
- BCompatibilidad, usabilidad y seguridad.
- CCompatibilidad, portabilidad y seguridad.
- DCompatibilidad, seguridad y adecuación funcional.
16En el marco de la ISO/IEC 25000 la interoperabilidad es una subcaracteristica de:
- ALa fiabilidad.
- BLa seguridad.
- CLa mantenibilidad.
- DLa compatibilidad.
17En el marco de la ISO/IEC 25000 la reusabilidad es una subcaracteristica de :
- ALa mantenibilidad.
- BLa seguridad.
- CLa fiabilidad.
- DLa compatibilidad.
18En el marco de la ISO/IEC 25000 la mantenibilidad es:
- ALa capacidad del producto software para ser modificado debido a necesidades
evolutivas, correctivas o perfectivas. - BLa capacidad del producto software para ser modificado efectiva y eficientemente,
debido a necesidades evolutivas, correctivas o perfectivas. - CLa capacidad del producto software para ser probado efectiva y eficientemente,
debido a necesidades evolutivas, correctivas o perfectivas. - DCapacidad de dos o más sistemas o componentes para intercambiar información
y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno
hardware o software.
- ALa capacidad del producto software para ser modificado debido a necesidades
19En el marco de la ISO/IEC 25000 la compatibilidad es :
- ACapacidad de dos o más sistemas o componentes para llevar a cabo sus funciones
requeridas cuando comparten el mismo entorno hardware o software. - BLa capacidad del producto software para ser modificado efectiva y eficientemente,
debido a necesidades evolutivas, correctivas o perfectivas. - CCapacidad de dos o más sistemas o componentes para intercambiar información
cuando comparten el mismo entorno hardware o software. - DCapacidad de dos o más sistemas o componentes para intercambiar información y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno
hardware o software.
- ACapacidad de dos o más sistemas o componentes para llevar a cabo sus funciones
20En el marco de la ISO/IEC 25000 la complejidad ciclomática está relacionada con:
- ALa seguridad.
- BLa compatibilidad y mantenibilidad.
- CLa mantenibilidad.
- DLa usabilidad y la compatibilidad.
21En el marco de la ISO/IEC 25000 la complejidad ciclomática está relacionada con :
- AEsfuerzo necesario para poder probar todos los caminos en un código fuente.
- BEsfuerzo necesario para poder probar todos los bucles en un código fuente.
- CEsfuerzo necesario para poder probar todos las funciones en un código fuente.
- DEsfuerzo necesario para poder probar todas las estructuras condicionales en un
código fuente.
22En el marco de la ISO/IEC 25000 la complejidad ciclomática se define como:
- Av(G) = e n + 2, donde n representa el número de aristas y e el número de nodos.
- Bv(G) = e n + 2, donde e representa el número de líneas de código que no son comentarios y n el número de líneas de comentarios.
- Cv(G) = e n + 2, donde e representa el número de nodos y n el número de aristas.
- Dv(G) = e n + 2, donde e representa el número de aristas y n el número de nodos.
23Según Thomas McCabe un valor de complejidad ciclomática mayor de 20 implica un riesgo:
- AAlto o altísimo en la capacidad de ser analizado un código fuente.
- BModerado en la capacidad de ser analizado un código fuente.
- CAlto en la capacidad de ser analizado un código fuente.
- DDespreciable en la capacidad de ser analizado un código fuente.
24Según Thomas McCabe un valor de complejidad ciclomática mayor de 50 implica un riesgo:
- AAlto o altísimo en la capacidad de ser analizado un código fuente.
- BModerado en la capacidad de ser analizado un código fuente.
- CAltísimo en la capacidad de ser analizado un código fuente.
- DDespreciable en la capacidad de ser analizado un código fuente.
25En el marco de la ISO/IEC 25000 la densidad de código repetido indica la relación entre la cantidad de :
- AComentarios de un producto y su tamaño (sin incluir comentarios).
- BCódigo repetido de un producto y su tamaño (sin contar comentarios).
- CCódigo repetido de un producto y su tamaño (contando comentarios).
- DComentarios de un producto y su tamaño (obviamente, incluyendo comentarios).
26En el marco de la ISO/IEC 25000 la densidad de comentarios indica la relación entre la cantidad de:
- AComentarios de un producto y su tamaño (sin incluir comentarios).
- BCódigo repetido de un producto y su tamaño (sin contar comentarios).
- CCódigo repetido de un producto y su tamaño (contando comentarios).
- DComentarios de un producto y su tamaño (obviamente, incluyendo comentarios).
27En el marco de la ISO/IEC 25000 la accesibilidad es una dimensión de la:
- AUsabilidad.
- BLa mantenibilidad
- CLa seguridad
- DLa complejidad ciclomática
28Para evaluar el nivel de accesibilidad de una aplicación web, un auditor usará como referente:
- ALa UNE 139803:2012 de ENAC.
- BLa UNE 139803:2012 de ISO.
- CLa UNE 139803:2012 de AENOR.
- DLa UNE 139803:2012 de BSI.
29Según la UNE 139803:2012 los niveles de conformidad respecto a la accesibilidad de una aplicación web son:
- AA, AA, AAA y AAAA.
- BA, AA y AAA.
- CA y AAA.
- DA, BB y CCC.
30Respecto a una aplicación web, TAWDIS es un test para evaluar su nivel de conformidad respecto a la:
- AUsabilidad.
- BMantenibilidad.
- CAccesibilidad.
- DModularidad.
311. La calidad del software depende de la calidad e los siguientes elementos:
- AEl proceso de desarrollo software, el proyecto, el equipo y el producto software.
- BEl proceso de explotación del software, las herramientas, el equipo y el producto software
- CEl proceso de desarrollo software, el proyecto y el producto software
- DEl proceso de pruebas del software, el equipo y el producto software
32El proceso de desarrollo software se puede implementar según el referente
- AISO/IEC 15504
- BFamilia ISO/IEC 25000
- CISO/IEC 27001
- DISO/IEC 12207
33Un auditor puede evaluar la capacidad de los procesos de la ISO/IEC 12207 utilizando:
- AISO/IEC 15504
- BISO 19011
- CISO/IEC 14598
- DFamilia ISO/IEC 25000
34El modelo de la calidad de los procesos software según la ISO está formado por:
- ACCMDI-DEV e ISO/IEC 15504
- BISO/IEC 12207, ISO/IEC 15504 y CCMI-DEV
- CISO/IEC 12207 e ISO/IEC 15504
- DISO/IEC 12207 e ISO/IEC 27001
35Respecto a la ISO/IEC 12207
- AEspecifica que procesos hay que implementar en un proceso de desarrollo de software
- BEspecifica cómo hay que implementar los procesos de desarrollo software
- CEspecifica cómo se evalúan los procesos de desarrollo software
- DEspecifica cómo se evalúa la calidad del producto software
36Si un auditor ha definido que una factoria software esta en un nivel de madurez 1 , ha revisado los siguientes procesos:
- ADe un suministro de gestión del modelo de ciclo de vida y gestión de la configuración software
- BDe un suministro, de planificación del proyecto y gestión de la configuración software
- CDe suministro, de gestión del modelo de ciclo de vida y gestión de la configuración software
- DDe aseguramiento de la calidad, de gestión del modelo de ciclo de vida y gestión de la configuración software
37Si un auditor ha definido que una organización de desarrollo software esta en el nivel de madurez 2, ha comprobado que la capacidad de los procesos correspondientes es:
- AAl menos dos para la mitad de los mismos
- BAl menos dos para los más importantes
- CDos
- DUno para la cuarta parte, dos para la mitad y tres para la cuarta parte
38Un auditor concluirá que un proceso de la ISO/IEC 12207 alcanza el nivel de capacidad 1, si constata que:
- ASe generan los “outcomes” o resultados del proceso según la ISO/IEC 15504
- BSe generan los “outcomes” o resultados del proceso según la ISO/IEC 12207
- CSe generan los “outcomes” o resultados del proceso según la ISO/IEC 14598
- DSe generan al menos la mitad de los “outcomes” o resultados del proceso según la ISO/IEC 12207
39Una certificación de la calidad de los procesos software (una evaluación CMMI por ejemplo):
- ASiempre asegura un producto de calidad software
- BNo tiene relación con un producto de calidad de software
- CNo existe el concepto de certificación de la calidad de los procesos software
- DNo siempre asegura un producto de calidad de software
40SPICE es el método para realizar auditorías de procesos de desarrollo software relacionado con:
- AISO/IEC 12207
- BCMMI-DEV
- CSQUARE
- DISO/IEC 9126
41SACMPI es el método para realizar auditorías de procesos de desarrollo software relacionado con
- AISO/IEC 12207
- BCMMI-DEV
- CSPICE
- DISO/IEC 9126
42CMMI-DEV es similar a:
- AISO/IEC 15504
- BISO/IEC 9126
- CISO/IEC 12207
- DISO/IEC 14598
43En una auditoria de proceso software un auditor de AENOR utiliza los siguientes estándares:
- AISO 19011, ISO/IEC 9126 e ISO/IEC 15504
- BISO 19011, ISO/IEC 12207 e CMMI-DEV
- CISO 19011, ISO/IEC 12207 e ISO/IEC 14598
- Dd) ISO 19011, ISO/IEC 12207 e ISO/IEC 15504
44En relación con el proceso de desarrollo software, la ISO/IEC 12207 especifica:
- AComo se debe hacer (metodología) y lo que se debe hacer
- BLo que se debe hacer
- CComo se evalúa la capacidad de los procesos que describe
- DComo se debe hacer (metodología)
45Tras auditar el proceso de desarrollo software una factoría software, el auditor asigna:
- AUn nivel de capacidad a la factoría y un nivel de madurez a los procesos auditados.
- BUn nivel de capacidad a la factoría
- CUn nivel de madurez a la factoría.
- DUn nivel de madurez a la factoría y un nivel de madurez a los procesos auditados.
46Para que un proceso de la ISO/IEC 12207 alcance el nivel de capacidad 2:
- ANo es necesario que se generen todos los “outcomes” o resultados del proceso según la ISO/IEC 12207.
- BEs necesario que se generen al menos la mitad de los “outcomes” o resultados del proceso según la ISO/IEC 12207
- CEs necesario que se generen todos los “outcomes” o resultados del proceso según la ISO/IEC 15504
- DEs necesario que se generen todos los “outcomes” o resultados del proceso según la ISO/IEC 12207
47Si el auditor constata que los 3 procesos del nivel de madurez 1 y los 7 niveles de madurez 2 alcanzan el nivel de capacidad 2 puede concluir que :
- ALa organización auditada se encuentra en un nivel de capacidad 2 y en un nivel de madurez 2
- BLa organización auditada se encuentra en un nivel de madurez 2
- CLa organización auditada se encuentra en un nivel de capacidad 2 para los 3 procesos del nivel de madurez 1 y los 7 procesos del nivel de madurez 2
- DLa organización auditada se encuentra en un nivel de capacidad 2
4818. Las evidencias directas en una auditoria SPICE pueden ser:
- AEl propio producto que se obtiene de un “outcome” o un AP.
- BCorreos, actas de reunión, planes, hitos, fechas, etc.
- CEl propio producto que se obtiene de un “outcome”;
- DEl propio producto que se obtiene de un “outcome” o un PA
49Las evidencias indirectas de una auditoria SPICE pueden ser:
- AEl propio producto que se obtiene de un “outcome” o un AP
- BCorreos, actas de reunión, planes, hitos, fechas, etc.
- CCorreos, actas de reunión, planes, hitos, “outcomes”, etc;
- DCorreos, AP, PA planes, hitos fechas, etc.
50Las evidencias de tipo afirmaciones en una auditoria se pueden obtener en;
- AEntrevistas con distintos actores de la organización y en “outcomes”
- BEntrevistas con distintos actores de la organización auditada y en evidencias indirectas
- CEntrevistas con distintos actores de la organización auditada y en correos
- DEntrevistas con distintos actores de la organización
51¿Qué estándar ha adoptado ISACA para evaluar los procesos de COBIT 5?
- AISO/IEC 15504
- BISO/IEC 12207
- CCMMI-DEV
- DISO/IEC 14598
52SQUARE es el método para realizar auditorías de procesos de desarrollo software relacionado con:
- AISO/IEC 12207
- BCMMi-DEV
- CSPICE
- DISO/IEC 9126
Information
- Description
- Quiz on AI07-08, created by Guillermo Rius on 27/05/2017.
- Author
- Guillermo Rius
- Language
- Español
- Views
- 114
- Rating
- No ratings yet Rate this quiz