1. ¿Qué es una métrica de proceso?

Se recopilan datos de calidad y productividad, estos se analizan, se comparan con promedios

anteriores y luego se valora las mejoras, también puntualiza áreas problemáticas para
desarrollar soluciones, así el proceso del sistema pueda mejorarse en la cual se recopilan
datos de calidad y productividad, estos se analizan, se comparan con promedios anteriores y
luego se valora las mejoras, también puntualiza áreas problemáticas para desarrollar
soluciones, así el proceso del sistema pueda mejorarse.

2. ¿Quién hace las métricas de proceso y proyecto?

a) Gerentes de software
b) Analista de software

3. ¿Cuál es la importancia de las métricas de proceso y proyecto?

a) Si no existe la medición, la evaluación será subjetiva.
b) Conocer las tendencias (buenas o malas)
c) Hacer mejores estimaciones
d) Lograr mejoras
4. ¿Cuál es la razón por la que se mide las métricas de proceso?
a) Para caracterizar un esfuerzo y obtener comprensión “de los procesos, productos, recursos
y entornos, y establecer líneas de referencia para comparar con valoraciones futuras”;
b) Para evaluar y “determinar el estado de avance con respecto a los planes”;
c) Para predecir al “obtener comprensión de las relaciones entre procesos y productos, y
construir modelos de dichas relaciones”.
d) Para mejorar al “identificar barricadas, causas raíz, ineficiencias y otras oportunidades para
mejorar la calidad del producto y el desempeño del proceso”.

5. ¿Cuáles son las métricas de proyecto permiten al gerente de un proyecto de software?

a) Valorar el estado de un proyecto en marcha,
b) Rastrear riesgos potenciales,
c) Descubrir áreas problema antes de que se vuelvan “críticas”,
d) Ajustar el flujo de trabajo o las tareas y
e) Evaluar la habilidad del equipo del proyecto para controlar la calidad de los productos
operativos del software.

6. ¿Cuáles son las métricas del proceso y la mejora del proceso de software?
Desarrollar un conjunto de métricas significativas con base en dichos atributos y luego usarlas
para proporcionar indicadores que conducirán a una estrategia para mejorar, es importante
observar que el proceso sólo es uno de varios “factores controlables en el mejoramiento de la
calidad del software y del desempeño organizativo”.

7. ¿Cuáles son los factores de la calidad de software?

El proceso se asienta en el centro de un triángulo que conecta tres factores que tienen profunda
influencia sobre la calidad del software y en el desempeño de la organización.
La habilidad y motivación del personal puede ser el factor individual más influyente en la calidad
y el desempeño.
La complejidad del producto puede tener un impacto sustancial sobre la calidad y el
desempeño del equipo.
La tecnología (es decir, los métodos y herramientas de la ingeniería del software) que puebla
el proceso también tiene un impacto.

8. ¿Como se puede medir la eficacia de un proceso de software?

a) Medidas de los errores descubiertos antes de liberar el software, defectos entregados a y
reportados por usuarios finales, productos operativos entregados (productividad), esfuerzo
humano empleado, tiempo calendario consumido, conformidad con la agenda y otras
medidas.
b) Medida de las características de tareas de ingeniería de software específicas. Por ejemplo,
puede medirse el esfuerzo y el tiempo empleados al realizar las actividades sombrilla y las
actividades genéricas de ingeniería del software.

9. ¿Cuál es la diferencia entre usos privado y público para las métricas del software?
Los ingenieros de software individual puedan ser sensibles al uso de las métricas recopiladas
de manera individual, dichos datos deben ser privados para el individuo y funcionar sólo como
un indicio para él. Los ejemplos de métricas privadas incluyen tasas de defecto (por individuo),
tasas de defecto (por componente) y errores que se encuentran durante el desarrollo.
Algunas métricas de proceso son privadas para el equipo de proyecto del software y públicas
para todos los miembros del equipo.

10. ¿Qué lineamientos deben aplicarse cuando se recopilan métricas de software?

a) Usar el sentido común y sensibilidad organizacional cuando se interpreten datos de
métricas.
b) Proporcionar retroalimentación regular a los individuos y equipos que recopilan medidas y
métricas.
c) No usar métricas para valorar a los individuos.
d) Trabajar con los profesionales y con los equipos para establecer metas y métricas claras
que se usarán para lograr las primeras.
e) Nunca usar métricas para amenazar a los individuos o a los equipos.
f) No considerar “negativos” los datos de métricas que indiquen un área problemática. Dichos
datos simplemente son un indicio para mejorar el proceso.
g) No obsesionarse con una sola métrica ni excluir otras métricas importantes.

11. ¿Cómo deben usarse las métricas durante el proyecto en sí?

a) Primero, se usan para minimizar el calendario de desarrollo al hacer los ajustes necesarios
para evitar demoras y mitigar potenciales problemas y riesgos.
b) Segundo, se usan para valorar la calidad del producto sobre una base en marcha y, cuando
es necesario, modificar el enfoque técnico para mejorar la calidad.
c) Conforme la calidad mejora, los defectos se minimizan.
d) conforme el conteo de defectos baja, la cantidad de reelaboración requerida durante el
proyecto también se reduce. Esto conduce a una reducción en el costo global del proyecto.

12. ¿Como se clasifican las mediciones de software?

a) Las medidas directas del proceso de software incluyen costo y esfuerzo aplicado. Las
medidas directas del producto incluyen líneas de código (LOC) producidas, rapidez de
ejecución, tamaño de memoria y defectos reportados sobre cierto espacio de tiempo.
b) Las medidas indirectas del producto incluyen funcionalidad, calidad, complejidad,
eficiencia, confiabilidad, capacidad de mantenimiento y muchas otras “habilidades”.

13. ¿Cuáles son las métricas orientadas a tamaño?

a) Se derivan al normalizar las medidas de calidad y/o productividad para considerar el
tamaño del software que se produjo.
b) Si una organización de software mantiene registros simples, puede crearse una tabla de
medidas orientadas a tamaño.
c) Con la finalidad de desarrollar métricas que puedan asimilarse con métricas similares de
otros proyectos, pueden elegirse líneas de códigos como un valor de normalización.
d) Las métricas orientadas a tamaño no se aceptan universalmente como la mejor forma de
medir el proceso de software.

14. ¿Cuáles son sus desventajas?

a) No se aceptan universalmente como la mejor forma de medir el proceso de software.
b) los opositores argumentan que las medidas LOC dependen del lenguaje de programación.
c) Que cuando se considera la productividad, castigan a los programas bien diseñados pero
cortos.
d) Que no pueden acomodarse con facilidad en lenguajes no procedurales.
e) Su uso en la estimación requiere un nivel de detalle que puede ser difícil de lograr (es decir,
el planificador debe estimar las LOC que se van a producir mucho antes de completar el
análisis y el diseño).
15. ¿Que define unas métricas orientadas a función?
a) Usan una medida de la funcionalidad entregada por la aplicación como un valor de norma-
lización.
b) El punto de función (PF) es la técnica métrica de mayor uso, se basa en características del
dominio y de la complejidad de información del software.
c) El PF es ideal para aplicaciones que usan lenguajes convencionales y no procedurales.
16. ¿Cuáles son las desventajas de una métrica orientada a función?
a) Sus opositores afirman que el método requiere cierta “maña”,
b) Se basa en datos subjetivos más que objetivos
c) El conteo del dominio de información (y otras dimensiones) puede ser difícil de recopilar
después del hecho
d) El PF no tiene significado físico directo: es sólo un número.
17. ¿Qué relación tiene las métricas LOC y PF?
a) La relación entre líneas de código y puntos de función depende del lenguaje de programa-
ción que se use para implementar el software y la calidad del diseño.
b) Las medidas LOC y PF se usan frecuentemente para calcular métricas de productividad.
c) Son predictores relativamente precisos del esfuerzo y del costo en el desarrollo del soft-
ware.
18. ¿Que logramos definir de métricas orientadas a objeto?
Es una secuencia detallada de pasos que describen la interacción entre el usuario y la
aplicación. Cada guion se organiza en tripletas de la forma {iniciador, acción, participante}
a) Iniciador es el objeto que solicita cierto servicio (que inicia un mensaje).
b) Acción es el resultado de la solicitud.
c) Participante es el objeto servidor que satisface la solicitud.
19. ¿Cómo se logra una métrica para calidad de software?
Deben aplicarse métodos efectivos acoplados con herramientas modernas dentro del contexto
de un proceso de software maduro. La calidad de un sistema, aplicación o producto sólo es
tan buena como los:

a) requerimientos que describen el problema,

b) el diseño que modela la solución,
c) el código que conduce a un programa ejecutable
d) las pruebas que ejercitan el software para descubrir errores.
e) Conforme el software se somete a ingeniería
20. ¿Se puede buscar calidad en base a los errores?
Métricas como errores de producto operativo por punto de función, errores descubiertos por
hora de revisión y errores descubiertos por prueba por hora proporcionan comprensión de la
eficacia de cada una de las actividades implicadas por la métrica. Los datos de error también
pueden usarse para calcular la eficiencia de remoción de defecto (ERD) para cada actividad
de marco conceptual del proceso.

21. ¿Por qué es tan importante medir el proceso de ingeniería del software y del producto
(software) que da como resultado?
a) Si no se mide, no hay forma real de determinar si se está mejorando. Y si no se mejora, se
está perdido.
b) Establecer metas significativas para mejorar el proceso de software.
c) Si puede mejorarse el proceso a través del cual se desarrolla, puede tenerse como resul-
tado un impacto directo sobre la línea de referencia.
d) Permite establecer una línea de referencia del proceso desde el cual puedan valorarse las
mejoras.
22. ¿De qué se deben preocupar los gerentes de proyecto de software?
a) desarrollar estimaciones de proyecto significativas.
b) producir sistemas de alta calidad.
c) sacar el producto a tiempo.
23. ¿Para qué se establece una línea de referencia?
Al establecer una línea de referencia para métricas, pueden obtenerse beneficios en el proceso,
el proyecto y el producto (técnico).
La línea de referencia de métricas consiste en los datos recopilados a partir de los proyectos
de desarrollo de software.

24. ¿Qué atributos deben tener los datos de la línea de referencia?

a) deben ser razonablemente precisos y deben evitarse “suposiciones” acerca de los
proyectos anteriores,
b) deben recopilarse para tantos proyectos como sea posible,
c) deben ser consistentes (por ejemplo, una línea de código debe interpretarse
consistentemente a través de todos los proyectos para los cuales se recopilan datos),
d) las aplicaciones deben ser similares al trabajo que debe estimarse: tiene poco sentido usar
una línea de referencia para el trabajo de sistemas de información en lote a fin de estimar
una aplicación incrustada en tiempo real.

25. ¿Cómo debe derivarse un conjunto de métricas de software “simples”?

Puede comenzarse con un enfoque en los resultados, no en la medición. Se consulta al grupo
de software para definir un solo objetivo que requiera mejora. Por ejemplo, “reducir el tiempo
para evaluar e implementar las peticiones de cambio”.

16. ¿Qué pasos sugiere el manual para establecer un programa de métricas del software?
a) Identificar las metas empresariales.
b) Identificar lo que se quiere conocer o aprender.
c) Identificar la submetas.
d) Identificar las entidades y atributos relacionados con la submetas.
e) Formalizar las metas de medición.
f) Identificar preguntas cuantificables y los indicadores relacionados que se usarán para
ayudar a lograr las metas de medición.
g) Identificar los elementos de datos que se recopilarán para construir los indicadores que
ayuden a responder las preguntas.
h) Definir las medidas que se van a usar y hacer operativas estas definiciones.
i) Identificar las acciones que se tomarán para implementar las medidas.
j) Preparar un plan para la implantación de las medidas.