¿Quién está interesado en evaluar la calidad? Organismos o empresas que adquieren productos software y organismos o empresas que externalizan total o parcialmente su proceso de desarrollo software. Factorías y empresas desarrolladoras de software y organismos o empresas que externalizan total o parcialmente su proceso de desarrollo software Factorí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. Factorías y empresas desarrolladoras de software, organismos o empresas que adquieren productos software y organismos o empresas que externalizan total o parcialmente su proceso de desarrollo software.
Factorías y empresas desarrolladoras de software, ¿están interesadas en evaluar la calidad de su software? No, porque hoy los clientes compran software basándose exclusivamente en el precio. Si, porque así venden más. Sí, porque así pueden asegurar a sus clientes que sus productos son de calidad. Sí, porque así pueden externalizar sus procesos de desarrollo software con garantía.
La deuda técnica hace referencia a: Consecuencias y costes en que incurre una empresa por externalizar software con debilidades. Consecuencias y costes en que incurre una empresa por comprar software con debilidades. Consecuencias y costes en que incurre una empresa por desarrollar software con debilidades. Consecuencias y costes en que incurre una empresa por desarrollar software sin debilidades.
La deuda técnica no intencionada viene dada por: Có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. Código de baja calidad por un programador junior o de adquisición de una empresa con deuda técnica. Có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>>. Código de baja calidad por un programador junior o asumir un equipo de baja calidad.
La deuda técnica intencionada viene dada por: Código de baja calidad por un programador junior o asumir un equipo de baja calidad. Có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. Subprocesos de desarrollo de baja calidad o presión de fechas <<Time to market>> o adquisición de una empresa con deuda técnica. Subprocesos de desarrollo de baja calidad o presión de fechas <<Time to market>> o pruebas y testing pobres.
La deuda técnica es: Es visible y genera valores negativos. Es invisible y genera valores negativos. Es visible y genera valores positivos. Es invisible y genera valores positivos.
Las características según el modelo de calidad del producto software recogidas en la ISO/IEC 9126 son: Funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad. Funcionalidad, fiabilidad, usabilidad, confidencialidad, mantenibilidad y portabilidad. Funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y trazabilidad. Racionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.
Según el modelo de calidad del producto software de la ISO/IEC 9126 las métricas internas: Son aplicables a la utilización del software por parte de los usuarios. Son aplicables el software en ejecución. No dependen de la ejecución del software y son, por lo tanto, medidas estáticas. No dependen de la ejecución del software y son, por tanto, medidas dinámicas.
Según el modelo de calidad del producto software de la ISO/IEC 9126 las métricas externas: Son aplicables a la utilización del software por parte de los usuarios. Son aplicables al software en ejecución. No dependen de la ejecución del software y son, por lo tanto, medidas estáticas. Son aplicables al software en ejecución y la utilización del software por parte de los usuarios.
Según el modelo de calidad del producto software de la ISO/IEC 9126 las métricas en uso: Son aplicables a la utilización del software por parte de los usuarios. Son aplicables al software en ejecución. No dependen de la ejecución de software y son, por lo tanto, medidas estáticas. Son aplicables a la utilización del software por parte de los usuarios y no es necesario que el software esté en ejecución.
La ISO/IEC 14598 es un marco de trabajo para: Evaluar la calidad de los procesos de desarrollo software. Evaluar la calidad de los productos de software. Evaluar la calidad de los productos de software y de los procesos de desarrollo software. Definir un modelo de calidad del producto software.
El referente que usara un auditor para evaluar la calidad de un producto software es: ISO/IEC 25000. ISO/IEC 14598. ISO/IEC 15504. ISO/IEC 19011.
En una auditoría de producto software un auditor de AENOR utiliza los siguientes estándares: ISO/IEC 19011, ISO/IEC 9126 e ISO/IEC 27001. ISO/IEC 15504, ISO/IEC 9126 e ISO/IEC 14598. ISO/IEC 19011, ISO/IEC 9000 e ISO/IEC 14598. ISO/IEC 19011, ISO/IEC 9126 e ISO/IEC 14598.
La calidad del producto software se puede interpretar como: El grado en que dicho producto satisface los requisitos del CEO y CIO aportando de esta manera un valor. El grado en que dicho producto satisface los requisitos de sus desarrolladores aportando de esta manera un valor. El grado en que dicho producto satisface los requisitos de sus usuarios aportando de esta manera un valor. El grado en que dicho producto satisface los requisitos de sus usuarios.
La ISO/IEC 25000 hereda la característica de calidad de la ISO/IEC 9126 y añade: Compatibilidad y seguridad. Compatibilidad, usabilidad y seguridad. Compatibilidad, portabilidad y seguridad. Compatibilidad, seguridad y adecuación funcional.
En el marco de la ISO/IEC 25000 la interoperabilidad es una subcaracterística de: La fiabilidad. La seguridad. La mantenibilidad. La compatibilidad.
En el marco de la ISO/IEC 25000 la reusabilidad es una subcaracterística de: La mantenibilidad. La seguridad. La fiabilidad. La compatibilidad.
En el marco de la ISO/IEC 25000 la mantenibilidad es: La capacidad del producto software para ser modificado debido a necesidades evolutivas, correctivas o perfectivas. La capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidad evolutivas, correctivas o perfectivas. La capacidad del producto software para ser probado efectiva y eficientemente, debido a necesidad evolutivas, correctivas o perfectivas. Capacidad 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.
En el marco de la ISO/IEC 25000 la compatibilidad es: La capacidad del producto software para ser modificado debido a necesidades evolutivas, correctivas o perfectivas. La capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidad evolutivas, correctivas o perfectivas. La capacidad del producto software para ser probado efectiva y eficientemente, debido a necesidad evolutivas, correctivas o perfectivas. Capacidad 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.
En el marco de la ISO/IEC 25000 la complejidad ciclomática está relacionada con: La seguridad. La compatibilidad y mantenibilidad. La mantenibilidad. La usabilidad y la compatibilidad.
En el marco de la ISO/IEC 25000 la complejidad ciclomática está relacionada con: Esfuerzo necesario para poder probar todos los caminos en un código fuente. Esfuerzo necesario para poder probar todos los bucles en un código fuente. Esfuerzo necesario para poder probar todas las funciones en un código fuente. dEsfuerzo necesario para poder probar todas las estructuras condicionalidades en un código fuente.
En el marco de la ISO/IEC 25000 la complejidad ciclomática se define como: v(G) = e – n + 2, donde n representa el número de aristas y e el número de nodos. v(G) = e – n + 2, donde e representa el número de líneas del código que no son comentarios y n el número de líneas de comentarios. v(G) = e – n + 2, donde e representa el número de nodos y n el número de aristas. v(G) = e – n + 2, donde e representa el número de aristas y n el número de nodos.
Según Tomas McCabe un valor de complejidad ciclomática mayor de 20 implica un riesgo: Alto o altísimo en la capacidad de ser analizado un código fuente. Moderado en la capacidad de ser analizado un código fuente. Alto en la capacidad de ser analizado un código fuente. Despreciable en la capacidad de ser analizado un código fuente.
Según Tomas McCabe un valor de complejidad ciclomática mayor de 50 implica un riesgo: Alto o altísimo en la capacidad de ser analizado un código fuente. Moderado en la capacidad de ser analizado un código fuente. Altísimo en la capacidad de ser analizado un código fuente. Despreciable en la capacidad de ser analizado un código fuente.
En el marco de la ISO/IEC 25000 la densidad de código repetido indica la relación entre la cantidad de: Comentarios de un producto y su tamaño (sin incluir comentarios). Código repetido de un producto y su tamaño (sin contar comentarios). Código repetido de un producto y su tamaño (contando comentarios). Comentarios de un producto y su tamaño (obviamente, incluyendo comentarios).
En el marco de la ISO/IEC 25000 la densidad de comentarios indica la relación entre la cantidad de: Comentarios de un producto y su tamaño (sin incluir comentarios). Código repetido de un producto y su tamaño (sin contar comentarios). Código repetido de un producto y su tamaño (contando comentarios). Comentarios de un producto y su tamaño (obviamente, incluyendo comentarios).
En el marco de la ISO/IEC 25000 la accesibilidad es una dimensión de la: Usabilidad. La mantenibilidad. La seguridad. La complejidad ciclomática.
Para evaluar el nivel de accesibilidad de una aplicación web, un auditor usará como referente: La UNE 139803:2012 de ENAC. La UNE 139803:2012 de ISO. La UNE 139803:2012 de AENOR. La UNE 139803:2012 de BSI.
Según la UNE 139803:2012 los niveles de conformidad respecto a la accesibilidad de una aplicación web son: A, AA, AAA y AAAA. A, AA y AAA. A y AAA. A, BB y CCC.
Respecto a una aplicación web, TAWDIS es un test para evaluar su nivel de conformidad respecto a la: Usabilidad. Mantenibilidad. Accesibilidad. Modularidad.
|
