La calidad del software depende de la calidad de los siguientes elementos:
El proceso de desarrollo de software, el proyecto , el equipo y el producto software
El proceso de explotación del software , las herramientas, el equipo y el producto software El proceso del desarrollo software, el proyecto y el producto software
El proceso de pruebas del software, el equipo y el producto software.
.
El proceso de desarrollo del software se puede implementar según el referente
ISO/IEC 15004 Familia ISO/IEC 25000
ISO/IEC 27001
ISO/IEC 12207.
Un auditor puede evaluar la capacidad de los procesos ISO/IEC 12207 utilizando ISO/IEC 15504
ISO 19011
ISO/IEC 14598
Familia ISO/IEC 25000
.
El modelo de la calidad de los procesos del software según la ISO está formado por CCMI-DEV e ISO/IEC 15504
ISO/IEC 12207,ISO/IEC 15504 Y CCMI-DEV
ISO/IEC 12207 e ISO/IEC 15504
ISO/IEC 12207 e ISO/IEC 27001
.
¿Qué estándar ha adoptado ISACA para revaluar los procesos de COBIT 5?
ISO/IEC 15504
ISO/IEC 12207
CCMI-DEV
ISO/IEC 14598
.
Respecto a la ISO/IEC 12207
Especifica qué procesos hay que implementar en un proceso de desarrollo software
Especifica cómo hay que implementar los procesos de desarrollo software
Especifica cómo se evalúan los procesos de desarrollo software
Especifica cómo se evalúa la calidad del producto software
.
Si un auditor ha definido que una factoría software está en un nivel de madurez 1, ha revisado los siguientes procesos
De suministro ,de gestión del modelo de ciclo de vida y gestión de la configuración del software
De suministro,planificación del proyecto y gestión de la configuración del software
De suministro, de gestión del modelo de ciclo de vida y gestión de la configuración software
De aseguramiento, de gestión de ciclo de vida y gestión de la configuración software
.
Si un auditor ha definido que una organización de desarrollo software está en un nivel de madurez 2, ha comprobado que la capacidad de los procesos correspondientes es: Al menos dos para la mitad de los mismos
Al menos dos para los más importantes
Dos
Uno para la cuarta parte,dos para la mitad y tres para la cuarta parte
.
Un auditor concluirá que un proceso de ISO/IEC 12207, alcanza el nivel de capacidad uno , si contesta que:
se generan los “outcomes” o resultados del proceso según la la ISO/IEC 15504
se generan los “outcomes” o resultados del proceso según la la ISO/IEC 12207
se generan los “outcomes” o resultados del proceso según la la ISO/IEC 14598
se generan al menos la mitad los “outcomes” o resultados del proceso según la la ISO/IEC 12207
.
Una certificación de la calidad de los procesos software (una evaluación CMMi por ejemplo):
Siempre asegura un producto de calidad de software.
No tiene relación con un producto de calidad de software.
No existe el concepto de certificación de la calidad de los procesos software.
No siempre asegura un producto de calidad de software.
SPEC es el método para realizar auditorías de procesos de desarrollo de software relacionado con
ISO/IEC 12207
CMMi-DEV
SQUARE
ISO/IEC 9126
.
SCAMPI es el método para realizar auditorías de procesos de desarrollo software relacionado con:
ISO/IEC 12207
CMMi-DEV
SPICE
ISO/IEC 9126
.
CMMi-DEV es similar a:
ISO/IEC 15504
ISO/IEC 9126
ISO/IEC 12207
ISO/IEC 14598.
En una auditoría de proceso software un auditor de AENOR utiliza los siguientes estándares:
ISO 19011,ISO/IEC 9126 e ISO/IEC 15504
ISO 19011,ISO/IEC 12207 e CMMi-DEV ISO 19011,ISO/IEC 12207 e ISO/IEC 114598
ISO 19011,ISO/IEC 12207 e ISO/IEC 15504
.
En relación con el proceso de desarrollo software, la ISO/IEC 12207 específica:
Cómo se debe hacer(metodología) y lo que se debe hacer
Lo que se debe hacer
Cómo se evalúa la capacidad de los procesos que describe
Cómo se debe hacer
.
Tras auditar el proceso de desarrollo software en una factoría software , el auditor asigna
Un nivel de capacidad a la factoría y un nivel de madurez a los procesos auditados
Un nivel de capacidad a la factoría
Un nivel de madurez a la factoría Un nivel de madurez a la factoría y un nivel de madurez a los procesos auditados
.
Para que un proceso de la ISO/IEC 12207 alcance el nivel de capacidad dos:
No es necesario que se generen los “outcomes” o resultados del proceso según la ISO/IEC 12207
Es necesario que se generen al menos la mitad de los “outcomes” o resultados del proceso según la ISO/IEC 12207
Se generen los “outcomes” o resultados del proceso según la ISO/IEC 15504
Es necesario que generen todos los “outcomes” o resultados del proceso según la ISO/IEC 12207
.
Si el auditor constata que los 3 procesos del nivel de madurez 1 y los 7 procesos del nivel de madurez 2 alcanzan el nivel de capacidad 2 puede concluir que:
La organización auditada se encuentra en un nivel de capacidad 2 y un nivel de madurez 2
La organización auditada se encuentra en un nivel de madurez 2
La organización auditada se encuentra en un nivel de capacidad 2 para los 3 procesos de nivel de madurez 1 y los 7 procesos de madurez 2
La organización auditada se encuentra en un nivel de capacidad 2.
.
Las evidencias directas en una auditoría SPICE pueden ser:
El propio producto se obtiene de un “outcome” o un AP
Correos ,actas de reunión,planes ,hitos,fechas,etc
El propio producto que se obtiene de un ”outcome” El propio producto se obtiene de un “outcome” o un PA
.
Las evidencias indirectas en una auditoría SPICE pueden ser: El propio producto se obtiene de un “outcome” o un AP
Correos,actas de reunión,planes,hitos,fechas , etc
Correos,actas de reunión, planes,hitos,"outcomes" Correos,AP,PA,planes,hitos,fechas,etc.
Las evidencias de tipo afirmaciones en una auditoría se pueden obtener en: Entrevistas con distintos actores de la organización y en “outcomes”
Entrevistas con distintos actores de la organización auditada y en evidencias indirectas
Entrevistas con distintos actores de la organización auditada y en correos Entrevistas con distintos actores de la organización
.
¿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 organismo 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 asi venden mas. 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.
Consecuencia 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:
Es visible y genera valores negativos.
Es invisible y genera valores negativos. Es visible y general 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 al 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 son: 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én 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 subcaracteristica de: La fiabilidad.
La seguridad.
La mantenibilidad.
La compatibilidad.
.
En el marco de la ISO/IEC 25000 la reusabilidad es una subcaracteristica de 003A
La mantenibilidad.
La seguridad.
La manteniblidad. 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 necesidades evolutivas, correctivas o perfectivas. La capacidad del producto software para ser probado efectiva y eficientemente, debido a necesidades 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 :
Capacidad de dos o más sistemas o componentes para llevar a cabo sus funciones requeridas cuando comparten el mismo entorno hardware o software.
La capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas.
Capacidad de dos o más sistemas o componentes para intercambiar información cuando comparten el mismo entorno hardware o software.
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 todos las funciones en un código fuente. Esfuerzo necesario para poder probar todas las estructuras condicionales 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 de 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 Thomas 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 Thomas 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.
.
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 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.
|
