Esta lista es el resultado de mis propias reflexiones y consejos de mis colegas sobre el desarrollo de métricas de calidad de software. Las métricas de calidad del software son herramientas esenciales para garantizar que un producto brinde la mejor experiencia a sus usuarios. Tuve que desarrollar dichas métricas durante mi pasantía como gerente de programa. Viniendo a este mundo como un Ph.D. investigador y científico de datos era bastante complicado. Aquí están los consejos.  Los datos en el software no son normales  Las métricas de calidad del software deben medir cada paso  Las estadísticas son geniales, pero...  Comparte tu trabajo en progreso  Piensa en todos los usuarios  1 Los datos en el software no son normales   Lo primero que noté cuando comencé a ver cómo se mide la calidad del software fue la distribución de datos, es decir, la forma de los datos. Veamos cuánto se tarda en enviar un mensaje de un teléfono a otro, es decir, la latencia del mensaje.  Su intuición podría decirle que hay un tiempo estándar como 1 segundo, y luego algunas personas reciben los mensajes antes y otras los reciben más tarde. Esto sugeriría algo parecido a una distribución Normal (ver la imagen de arriba). Calcular una media podría parecer una buena métrica para medir la calidad si los datos de latencia estuvieran distribuidos normalmente.  Sin embargo, los datos en el software tienden a tener colas más largas en el lado derecho. Considere el ejemplo del mensaje. La mayoría de los mensajes se entregan al receptor en menos de 1 segundo. Aún así, algunos de ellos pueden tomar más tiempo y los tiempos específicos pueden variar de 2 segundos a 24 horas. Dichos datos podrían seguir   (diferente de la   o un Principio de Pareto) bien conocida en las aplicaciones de control de calidad. la distribución de Pareto regla 80/20  ¿Podemos usar este hecho en el desarrollo de métricas de calidad del software?  Pensar en la distribución de Pareto dirige nuestra atención a la cola y a considerar a todos nuestros usuarios, incluidos los desafortunados. Por lo tanto, nos enfocamos en las experiencias de usuario menos probables en lugar del medio correspondiente a una experiencia más probable.  Esto significa que calcularíamos percentiles o cuantiles más altos en lugar de calcular la latencia media del mensaje. Por ejemplo, el percentil 95 describiría la peor experiencia medida para el 95 % de todos los usuarios. Entonces podemos evaluar si eso es aceptable.  Tenga en cuenta que las palabras cuantil y percentil a menudo se usan indistintamente en la práctica, y existe una discrepancia entre las definiciones estadísticas reales.  Recomendaría este video para aclarar:   https://www.youtube.com/watch?v=IFKQLDmRK0Y  2 Las métricas de calidad del software deben medir cada paso  Cuando se trata de la calidad del software en el contexto de la gestión de productos, es fácil pensar principalmente en el front-end. Las partes específicas del front-end impactan claramente en la experiencia del usuario.  Después de todo, es lo que el usuario puede ver e interactuar. Sin embargo, las métricas de calidad del software para el back-end no deberían ser una ocurrencia tardía. Centrarse en partes individuales del back-end puede llevarlo a descubrir oportunidades para mejorar la velocidad de los procesos. Como probablemente sepa por su propia experiencia como humano que usa tecnología, odiamos esperar, por lo que las mejoras de velocidad son buenas.  3 Estadísticas es genial, pero...  Lo sé. Esto suena extraño viniendo de mí después de que el punto más largo de esta historia es sobre estadísticas. Eso debería decirle lo difícil que fue la transición de un contexto académico a uno empresarial y de la ciencia de datos a la gestión de productos.  Cuando comencé a desarrollar las métricas de calidad del software durante mi pasantía, traté de encontrar formas de medir la calidad del software que fueran computacionalmente eficientes, pero precisas. No pude evitarlo.  Luego le mostré esto a mi colega, y mientras le explicaba cómo funcionaría, me detuvo y me pidió que reflexionara sobre cuánto tiempo lleva explicar qué es. Tuve que preguntarme, ¿es mi propuesta mejor que los enfoques más estándar en todos los aspectos? Fue súper divertido para mí tratar de desarrollar algo nuevo. Sin embargo, luego estaba el aspecto de la comunicación. ¿Tendrá esto sentido para la alta dirección?  No quiere decir que no pueda usar estadísticas y cálculos más complejos en los negocios, pero incluso la navaja de Occam nos enseña a preferir lo simple a lo complicado. Los complicados algoritmos para estimar la calidad del software pueden ser geniales de desarrollar, pero son inútiles cuando la mayoría de las personas no entienden el resultado.  Si alguien te pide que pintes un retrato, no esperará un cuadro de Picasso.  4 Comparte tu trabajo en progreso  Fue sorprendente ver lo fácil que fue colaborar con las personas y cuánto valor aportaron al proceso general. En la mayoría de los sistemas escolares del mundo, a menudo se le evalúa según sus resultados individuales. Hay algunos proyectos de colaboración aquí y allá, pero la mayoría de nosotros aprendemos a confiar en nosotros mismos.  Si alguna vez ha tratado de aprender algo difícil, sabe que la mejor estrategia es seguir adelante e intentarlo hasta que lo haga bien. Esta perseverancia a veces puede obstaculizar nuestro progreso para hacer las cosas porque es posible que no pensemos en la colaboración como una herramienta.  Sorpresa sorpresa; las empresas quieren lograr los resultados lo antes posible. Aprovechar el conocimiento de sus colegas y recopilar comentarios sobre sus primeras ideas es la mejor manera de generar métricas de calidad de software que estén bien definidas y sean útiles en la toma de decisiones.  5 Piensa en todos los usuarios  Las métricas de calidad del software pueden medir diferentes capas de calidad. Podemos dirigir la atención hacia la función del producto, la experiencia del usuario pero también los aspectos técnicos. El software es complejo y, muy a menudo, los usuarios del producto o los clientes finales no son los únicos usuarios en los que debe pensar. Si está trabajando en un servicio de back-end, las personas que trabajan en el front-end son sus usuarios.  Por lo tanto, sus métricas de calidad de software deben considerar sus grupos de usuarios y qué tan lejos están de la pieza de software en la que está trabajando. Considere cuál es el impacto en los grupos de usuarios específicos cuando su métrica muestra un rendimiento mejorado o empeorado.  Métricas de calidad de software y ciencia de datos  La gestión de productos y la ciencia de datos tienen algunas superposiciones, y una de las más importantes son las métricas para la calidad del software. Si está pensando en cambiar su carrera de ciencia de datos, asegúrese de elegir las herramientas adecuadas de su caja de herramientas de ciencia de datos.  Como científico de datos, generalmente se enfoca en la codificación y las estadísticas, y la buena comunicación es una gran ventaja. Cuando trabaja como gerente técnico de productos o programas, la importancia de esas habilidades se invierte y la comunicación y la colaboración se vuelven cruciales.  Si se encuentra desarrollando métricas de calidad de software, también le recomendaría leer sobre el enfoque SixSigma   . crítico para la calidad  ¡Buena suerte!

Super

YouTube

2022 - HackerNoon Contributor of the Year - Communication

2022 - HackerNoon Contributor of the Year - Data Science

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Learning

2022 - HackerNoon Contributor of the Year - Science Fiction

2022 - HackerNoon Contributor of the Year - Self Improvement

Super Career Strategist of 2022

Instagram

Newsletter

Researcher, Data Scientist and Writer

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Make resilience your competitive advantage

Desarrollo de métricas de calidad de software como científico de datos: 5 lecciones aprendidas

Desarrollo de métricas de calidad de software como científico de datos: 5 lecciones aprendidas

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Una breve introducción a la teoría del cerebro de Boltzmann

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Una breve introducción a la teoría del cerebro de Boltzmann

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps