process - pruebas - metricas de rendimiento de software
¿Cuáles son las métricas de desarrollo de software más útiles? (26)
Me gustaría realizar un seguimiento de las métricas que pueden usarse para mejorar el proceso de desarrollo de software de mi equipo, mejorar las estimaciones de tiempo y detectar variaciones de casos especiales que deben abordarse durante la ejecución del proyecto.
Limite cada respuesta a una sola métrica, describa cómo usarla y vote las buenas respuestas.
Haga un seguimiento de si una fuente ha sido revisada y, de ser así, de qué tipo. Y luego, haga un seguimiento de la cantidad de errores encontrados en el código revisado y no revisado.
Esto le permitirá determinar qué tan efectivamente están operando los procesos de revisión de código en términos de errores encontrados.
Velocidad: la cantidad de características por unidad de tiempo determinada.
Depende de usted determinar cómo se definen las características, pero deben ser aproximadamente del mismo orden de magnitud, de lo contrario la velocidad es menos útil. Por ejemplo, puede clasificar sus características por historias o casos de uso. Estos deben ser desglosados de manera que sean aproximadamente del mismo tamaño. En cada iteración, averigüe cuántas historias (casos de uso) se implementaron (completaron). El número promedio de características / iteración es su velocidad. Una vez que conozca su velocidad en función de su unidad de función, puede usarla para ayudar a estimar cuánto tiempo llevará completar nuevos proyectos según sus características.
[EDITAR] Alternativamente, puede asignar un peso como puntos de función o puntos de historia a cada historia como una medida de complejidad, luego sumar los puntos para cada característica completa y calcular la velocidad en puntos / iteración.
Rastree la fuente y el tipo de errores que encuentre.
La fuente del error representa la fase de desarrollo en la que se introdujo el error. (por ejemplo, especificación, diseño, implementación, etc.)
El tipo de error es el estilo amplio de error. p.ej. asignación de memoria, condicional incorrecto.
Esto debería permitirle modificar los procedimientos que sigue en esa fase de desarrollo y ajustar su guía de estilo de codificación para tratar de eliminar los tipos de error sobre representados.
Si está usando Scrum, el retraso acumulado. ¿Qué tan grande es después de cada carrera? ¿Se está reduciendo a una velocidad constante? O las cosas se están metiendo en la acumulación debido a (a) cosas que no se pensó inicialmente ("Necesitamos otro caso de uso para un informe de auditoría en el que nadie pensó, lo agregaré a la cartera de pedidos). ") o (b) no hacer las cosas y colocarlas en la lista de espera para cumplir con la fecha en lugar de las características prometidas.
Si está usando Scrum, quiere saber cómo fue el Scrum de cada día. ¿Las personas están haciendo lo que dijeron que harían?
Personalmente, soy malo en eso. Crónicamente atropellé mis diarios.
Fan in y Fan out son mis favoritos.
Fan in: ¿Cuántos otros módulos / clases usan / conocen este módulo?
Fan out: ¿Cuántos otros módulos usa / sabe este módulo?
Cobertura de código inverso
Obtenga un porcentaje de código no ejecutado durante una prueba. Esto es similar a lo que mencionó Shafa, pero el uso es diferente. Si se ejecuta una línea de código durante la prueba, entonces sabemos que podría probarse. Pero si una línea de código no se ha ejecutado, entonces sabemos con certeza que no se ha probado. Dirigirse a estas áreas para pruebas unitarias mejorará la calidad y requiere menos tiempo que la auditoría del código que se ha cubierto. Lo ideal es que puedas hacer ambas cosas, pero eso nunca parece suceder.
Haga un seguimiento de cuánto tiempo lleva realizar una tarea que tiene una estimación en su contra. Si estaban muy por debajo, pregunta por qué. Si ya han terminado, pregunta por qué.
No lo conviertas en algo negativo, está bien si las tareas se agotan o si se subestiman demasiado. Tu objetivo es mejorar continuamente tu proceso de estimación.
Longitud de función promedio, o posiblemente un histograma de longitudes de función para obtener una mejor sensación.
Cuanto más larga es una función, menos obvia es su corrección. Si el código contiene muchas funciones largas, probablemente sea una apuesta segura que haya algunos errores escondidos allí.
Porcentaje de cobertura del código
interdependencia entre clases. qué tan apretado está tu código.
número de líneas similares. (código de copia / pegado)
número de pruebas fallidas o construcciones rotas por commit.
"mejorar el proceso de desarrollo de software de mi equipo": Búsqueda de defectos y tarifas de reparación
Esto se relaciona con la cantidad de defectos o errores surgidos en relación con la cantidad de correcciones que se han confirmado o comprometido.
Debo decir que esta es una de las métricas realmente importantes porque te da dos cosas:
Una tasa de arreglo baja indica que el equipo está ocupado trabajando en otras cosas (características quizás). Si el número de errores es alto, es posible que necesite que los desarrolladores solucionen algunos de los defectos.
Una baja tasa de búsqueda indica que su solución es brillante y casi libre de errores, o que el equipo de control de calidad ha sido bloqueado o tiene otro enfoque.
Tamaño y frecuencia de confirmaciones de control de origen.
mejorar el proceso de desarrollo de software de mi equipo
Es importante comprender que las métricas no pueden hacer nada para mejorar el proceso de desarrollo de software de su equipo. Todo lo que pueden usar es medir qué tan bien está avanzando hacia la mejora de su proceso de desarrollo con respecto a la métrica particular que está utilizando. Tal vez estoy discutiendo sobre la semántica, pero la forma en que lo está expresando es por qué la mayoría de los desarrolladores lo odian. Parece que está intentando usar métricas para generar un resultado en lugar de usar métricas para medir el resultado.
Para decirlo de otra manera, ¿preferiría tener una cobertura de código del 100% y pruebas unitarias pésimas o pruebas de unidad fantásticas y <80% de cobertura?
Tu respuesta debería ser la última. Incluso podría querer el mundo perfecto y tener ambos, pero será mejor que se centre primero en las pruebas de la unidad y permita que la cobertura llegue allí cuando lo haga.
mejorar las estimaciones de tiempo
Si bien la programación basada en evidencia de Joel Spolsky no es per se una métrica , parece exactamente lo que quieres. Ver http://www.joelonsoftware.com/items/2007/10/26.html
Rastree la cantidad de clones (fragmentos de código similares) en el código fuente.
Deshágase de los clones refaccionando el código tan pronto como detecte los clones.
ROI.
La cantidad total de ingresos generados por el software menos la cantidad total de costos para producir el software. Desglose los costos por porcentaje del costo total y aísle su área más pobre y más rentable en términos de rendimiento de la inversión. Mejore, automatice o elimine ese área problemática si es posible. Por el contrario, encuentre su área de mayor retorno de la inversión y encuentre maneras de amplificar aún más sus efectos. Si el 80% de su ROI proviene del 20% de su costo o esfuerzo, amplíe esa área en particular y minimice el resto en comparación.
Los costos incluirán nómina, licencias, honorarios legales, hardware, equipos de oficina, marketing, producción, distribución y soporte. Esto se puede hacer en un nivel macro para una empresa como un todo o un nivel micro para un equipo o individuo. También se puede aplicar a tiempo, tareas y métodos además de los ingresos.
Esto no significa ignorar todos los detalles, sino encontrar una forma de cuantificar todo y luego concentrarse en las áreas que producen los mejores resultados (objetivos).
Cada vez que el equipo de control de calidad informa un error, analice por qué ese defecto escapó a las pruebas unitarias de los desarrolladores.
Considere esto como un ejercicio de auto-mejora perpetua.
La mayoría de las medidas mencionadas anteriormente son interesantes, pero no lo ayudarán a mejorar el rendimiento del equipo. El problema es que estás haciendo una pregunta de gestión en un foro de desarrollo.
Aquí hay algunas métricas: Estimaciones / vs / reales en el nivel del cronograma del proyecto y en el nivel personal (ver el enlace anterior al método de Joel basado en Evidencia),% de defectos eliminados en el lanzamiento (ver mi blog: http://redrockresearch.org/? p = 58 ), fluencia / mes del alcance y calificación de productividad general (índice de productividad de Putnam). Además, el ancho de banda de los desarrolladores es bueno para medir.
Me gusta especialmente y uso el sistema que Mary Poppendieck recomienda . Este sistema se basa en tres mediciones holísticas que deben tomarse como un paquete (entonces, no, no voy a proporcionar 3 respuestas):
- Tiempo del ciclo
- Desde el concepto del producto hasta la primera versión o
- Desde la solicitud de funciones hasta la implementación de características o
- Desde la detección de errores hasta la resolución
- Realización de caso de negocio (sin esto, todo lo demás es irrelevante)
- P & L o
- ROI o
- Objetivo de inversión
- La satisfacción del cliente
- p. ej. puntaje neto del promotor
No necesito más para saber si estamos en fase con el objetivo final: proporcionar valor a los usuarios, y rápido.
Quizás puedas probar CodeHealer
CodeHealer realiza un análisis en profundidad del código fuente, buscando problemas en las siguientes áreas:
- Auditorías Reglas de control de calidad como código no utilizado o inalcanzable, uso de nombres de directivas y palabras clave como identificadores, identificadores que ocultan otros del mismo nombre en un ámbito superior y más.
- Verifica Errores potenciales como identificadores no inicializados o no referenciados, conversión de tipo peligroso, conversiones automáticas de tipo, valores de retorno de función indefinidos, valores asignados no utilizados, y más.
- Métricas Cuantificación de las propiedades del código, como complejidad ciclomática, acoplamiento entre objetos (acoplamiento de abstracción de datos), relación de comentarios, número de clases, líneas de código y más.
Me gustan las métricas de Eficacia de resolución de defectos. DRE es la proporción de defectos resueltos antes del lanzamiento del software contra todos los defectos encontrados. Sugiero seguir estas métricas para cada lanzamiento de su software en producción.
El seguimiento de las métricas en QA ha sido una actividad fundamental desde hace bastante tiempo. Pero a menudo, los equipos de desarrollo no analizan en su totalidad cuán relevantes son estas métricas en relación con todos los aspectos del negocio. Por ejemplo, las métricas de seguimiento típicas, como las proporciones de defectos, validez, productividad de prueba, cobertura de código, etc. generalmente se evalúan en términos de los aspectos funcionales del software, pero pocos prestan atención a cómo importan los aspectos comerciales del software.
También hay otras métricas que pueden agregar mucho valor a los aspectos comerciales del software, lo cual es muy importante cuando se mira una visión de calidad general del software. Estos se pueden clasificar en general en:
- Necesidades de los usuarios beta capturados por analistas de negocios, gente de marketing y ventas
- Requisitos del usuario final definidos por el equipo de gestión del producto
- Garantizar la disponibilidad del software en los picos de carga y la capacidad del software para integrarse con los sistemas informáticos de la empresa
- Soporte para transacciones de alto volumen
- Aspectos de seguridad dependiendo de la industria a la que sirve el software
- Disponibilidad de características indispensables y agradables en comparación con la competencia
- Y algunos más ...