Test capitulo 7 metricas

TEST BORRADO, QUIZÁS LE INTERESE: Capitulo 7 Metricas

COMENTARIOS	ESTADÍSTICAS	RÉCORDS

REALIZAR TEST

Título del Test:
Capitulo 7 Metricas

Descripción:
Test para Control de calidad

Autor:
alejandro

OTROS TESTS DEL AUTOR

Fecha de Creación: 06/09/2023

Categoría: Informática

Número Preguntas: 19

COMPARTE EL TEST

COMENTAR

No hay ningún comentario sobre este test.

Temario:

Una de las actividades importantes dentro de los principios de medición implica la adecuada interpretación, esto significa Evaluar la formulación de tal manera que las métricas representen una visión objetiva de la calidad del producto Evaluar los mecanismos para acumulación de datos de tal forma que estos presenten la suficiente confiabilidad de la calidad Efectuar las recomendaciones adecuadas y interpretarlas de tal forma que el equipo de software pueda tener las acciones correctivas correspondientes Evaluar los resultados de tal forma que se tenga una adecuada comprensión de la complejidad y calidad del productod).
Las métricas de diseño arquitectónico se enfocan en las características de la arquitectura del programa y los componentes dentro de esa arquitectura. En este contexto cual de las siguientes afirmaciones es correcta Estas métricas están relacionadas con la estructura modular del sistema y son de caja blanca Estas métricas requieren conocimiento del funcionamiento interno del componente y son de caja negra Estas métricas están relacionadas con la morfología y son de caja negra Estas métricas están relacionadas con la morfología y se enfocan en la cobertura.
Una métrica muy usada para la complejidad es la desarrollada por McCabe, esta se caracteriza por Permite conocer el tamaño global de una clase y se basa en el número de arcos y nodos Permite determinar la profundidad de una clase a través de la trayectoria más larga de nodos Permite determinar el encapsulamiento de sus clases a través de la ponderación de sus métricas Permite determinar la complejidad del flujo de control del programa a través del número de arcos y nodos.
En cuanto a la medición de software y sus procesos, estos se pueden agrupar en los siguientes macro-conjuntos de medidas Métricas de proceso, de CMMI y de proyecto Métricas de complejidad, de tamaño y de producto Métricas de producto, de proceso y de esfuerzo Métricas de producto, de proyecto y de proceso.
Un indicador (basado en una métrica o conjunto de métricas de software) proporcionan importante información al ingeniero para que éste tome acciones adecuadas. Entre otras proporciona Comprensión acerca del proceso del software, del proyecto o del producto en sí, lo que les permite hacer los ajustes necesarios. Comprensión acerca de la madurez del proceso del software y una visión de sus fortalezas y debilidades, para con ello tomar acciones correctivas. Comprensión acerca del estado del producto y su relación con la madurez del proceso de software, para en base a ello tomar acciones correctivas. Comprensión de la validez de los principios de formulación, recolección y análisis, para con ello estructurar medidas más asertivas del proceso.
Una métrica usada para determinar la especificidad está basada en la consistencia de la interpretación de los revisores para cada requisito. Según esto, si la métrica está dada por la razón (Nu / Nr), según lo estudiado en clase: Es sugerible que la métrica se aproxime a la unidad para que haya mayor especificidad. Es sugerible que la métrica tenga un valor mayor que 1 para que haya mayor especificidad. Es sugerible que la métrica sea diferente de cero para que haya mayor especificidad La especificidad es independiente del valor del índice calculado.
Empareje los siguientes conceptos Métricas de Proceso Métricas de Proyecto Métricas de Producto.
Hay ciertas consideraciones importantes en la relaciónCalidad SW – Métricas la firmacion correcta es La calidad del software se mide únicamente en función de la cantidad de código escrito y la velocidad de desarrollo. Las métricas en la calidad del software se centran principalmente en la satisfacción del usuario final, sin importar los estándares específicos La calidad del software no tiene relación con ningún estándar o métrica, ya que es subjetiva y varía según las necesidades del proyecto. Cumplir con un conjunto de criterios de desarrollo de software donde están involucrados estándares específicos, que guían la manera de cómo se debe hacer la ingeniería, si no se cumple existirá poca calidad.
Una de las actividades importantes dentro de los principios de medición implica la adecuada realimentacion, esto significa Recomendaciones derivadas de la evaluación de métricas del producto que se comunican al equipo de desarrollo de software. Recomendaciones extraídas de la evaluación de métricas del producto que se comunican al equipo de software. Recomendaciones basadas en la interpretación de métricas del producto que se comparten con el equipo de desarrollo de software Recomendaciones obtenidas a partir del análisis de métricas del producto que se transmiten al equipo de desarrollo de software.
Las métricas de diseño arquitectónico se enfocan en las características de la arquitectura del programa y los componentes dentro de esa arquitectura. En este contexto cual de las siguientes afirmaciones es correcta A medida que los niveles de complejidad se incrementan, la complejidad en la arquitectura o estructura global del sistema también se eleva. A medida que aumenta la complejidad, la simplicidad en la arquitectura global del sistema se incrementa Con el crecimiento de los valores de complejidad, la complejidad arquitectónica del sistema disminuye Cuando los valores de complejidad se reducen, la complejidad global del sistema también se reduce.
La razón mide la densidad de conectividad de la arquitectura y puede proporcionar un indicio simple del acoplamiento de la arquitectura esto se mide con: La relación entre el arco y el nodo, r, es igual a la suma de a más n El valor de r es igual a la raíz cuadrada de la relación entre a y n Para calcular r, se multiplica a por n El valor de r es igual a arco a nodo r, es a sobre n.
¿Cuál es uno de los indicadores razonables de la cantidad de esfuerzo requerido para implementar y probar una clase, así como su impacto en la reutilización y complejidad del árbol de herencia? El número de métodos y su complejidad no afectan el esfuerzo requerido para implementar y probar una clase El tamaño del árbol de herencia disminuye a medida que el número de métodos en una clase aumenta Una mayor cantidad de métodos en una clase promueve la reutilización de código. Mantener el número de métodos en una clase tan alto como sea posible es una práctica recomendada.
¿Qué representa la métrica DIT (Profundidad del Árbol de Herencia) en la jerarquía de clases y cuáles son sus implicaciones en términos de reutilización, complejidad de diseño y predicción del comportamiento de una clase? La métrica DIT mide la cantidad de métodos heredados por una clase y no tiene impacto en la complejidad de diseño ni en la reutilización. DIT representa la distancia entre un nodo y la raíz del árbol de herencia, y no tiene relación con la predicción del comportamiento de una clase. DIT representa la distancia entre un nodo y la raíz del árbol de herencia, y no tiene relación con la predicción del comportamiento de una clase. Cuanto mayor sea el valor de DIT, menor será la complejidad de diseño y las dificultades en la predicción del comportamiento de una clase.
¿Qué representa la métrica NOC (Número de Hijos) en una jerarquía de clases y cómo afecta al reúso y la cantidad de pruebas en el contexto de la programación orientada a objetos NOC mide la cantidad de pruebas realizadas en una jerarquía de clases y no tiene relación con el reúso o la estructura de la jerarquía. El NOC refleja la cantidad de hijos inmediatos de una clase, y a medida que este número aumenta, disminuye la cantidad de pruebas necesarias. NOC indica la cantidad de hijos directos de una clase, y a medida que este número crece, aumenta el potencial de reúso y la cantidad de pruebas requeridas. Cuanto mayor sea el NOC, menor será la cantidad de pruebas necesarias, pero también se reduce la capacidad de reutilización de métodos.
¿Qué se entiende por la métrica "Tamaño de la Clase" según Lorenz y Kidd y cuáles son los componentes que se utilizan para determinar el tamaño global de una clase en programación orientada a objetos? El "Tamaño de la Clase" se refiere al número de clases que heredan de una clase padre y no tiene relación con las operaciones y atributos encapsulados. El "Tamaño de la Clase" se calcula mediante el número total de clases en un programa y no tiene en cuenta las operaciones y atributos encapsulados. El "Tamaño de la Clase" se determina por el número de operaciones y atributos encapsulados en una clase, tanto heredados como de instancia privada. El "Tamaño de la Clase" se basa en la cantidad de relaciones de composición en una clase, excluyendo las operaciones y atributos.
¿Qué métrica de complejidad del flujo de control de programa es ampliamente utilizada y cuál es la fórmula para calcularla según Thomas McCabe? La métrica ampliamente utilizada es la "Complejidad de Flujo de Control" y se calcula como la diferencia entre el número de arcos (A) y el número de nodos (N) en un programa. La métrica comúnmente empleada es la "Complejidad Ciclomática", que se obtiene restando el número de nodos (N) al número de arcos (A) y sumando 2. La métrica principal es la "Complejidad de Software" y se calcula dividiendo el número de arcos (A) entre el número de nodos (N). La métrica más utilizada es la "Complejidad de Código" y se calcula sumando el número de arcos (A) y el número de nodos (N).
¿Cómo se determina el tamaño promedio de una operación según las métricas orientadas a operación y qué implicaciones puede tener un aumento en el número de mensajes enviados por una operación en términos de la asignación de responsabilidades dentro de una clase? El tamaño promedio de una operación se determina contando el número de atributos en una clase. Un aumento en el número de mensajes enviados por una operación no tiene impacto en la asignación de responsabilidades. El tamaño promedio de una operación se calcula mediante el número de líneas de código en la operación. Un aumento en el número de mensajes enviados por una operación puede indicar una mejor asignación de responsabilidades en una clase. El tamaño promedio de una operación se obtiene contando el número de mensajes enviados por la operación. Un aumento en el número de mensajes enviados por una operación sugiere una asignación deficiente de responsabilidades en la clase. El tamaño promedio de una operación se determina mediante la complejidad ciclomática de la operación. Un aumento en el número de mensajes enviados por una operación no afecta la asignación de responsabilidades.
¿Cuál es el significado del "Número promedio de parámetros por operación" (NPprom) según las métricas orientadas a operación, y cuál es la recomendación general en cuanto a su valor? El NPprom mide la cantidad de operaciones en un programa. Se recomienda que el NPprom sea alto para facilitar la colaboración entre objetos. El NPprom se refiere a la cantidad de líneas de código por operación en un programa. Se recomienda mantener el NPprom lo más alto posible. El NPprom indica la complejidad de la colaboración entre objetos en función del número de parámetros por operación. En general, se aconseja mantener el NPprom tan bajo como sea posible El NPprom se calcula dividiendo el número de operaciones entre el número de parámetros en un programa. Se recomienda mantener el NPprom en niveles moderados.
¿Cuáles son las tres medidas que proporcionan una indicación de la finalización de las pruebas y cuál es su propósito en el contexto de las métricas para pruebas? Las tres medidas son la "Medida de amplitud de las pruebas", la "Profundidad de las pruebas" y los "Perfiles de fallos". Su propósito es determinar la cantidad de errores en el código y priorizarlos. Las tres medidas son la "Proporción de requisitos probados", la "Medida de amplitud de las pruebas" y la "Profundidad de las pruebas". Sirven para evaluar la calidad del código y categorizar los errores. Las tres medidas son la "Proporción de requisitos probados", la "Medida del porcentaje de caminos básicos independientes probados" y los "Perfiles de fallos". Su objetivo es evaluar el progreso y la calidad de las pruebas. Las tres medidas son la "Proporción de requisitos probados", la "Medida del porcentaje de caminos básicos independientes probados" y la "Profundidad de las pruebas". Se utilizan para evaluar la cobertura de las pruebas y priorizar los errores.

Denunciar Test

▲