¿Midiendo el riesgo de cambios en el código fuente?

7

Mi administrador me pidió que escribiera una estimación de las horas de trabajo y una estimación del riesgo de los cambios en el código fuente para una tarea definida.

Si bien el primero no es un problema para mí y hay muchos recursos en la web, no puedo entender a este último.

Ya pedí una descripción más clara de la estimación del riesgo y obtuve la respuesta de que el riesgo de la necesidad de "cambios en el código de seguimiento debido a los cambios realizados" y "pérdida potencial de estabilidad del software en general" debe indicarse .

¿Cómo puedo abordar esta tarea (reglas en miniatura, documentos sobre la estimación de riesgos, ...)?

    
pregunta Bertolt 05.07.2011 - 12:38

3 respuestas

4

Su gerente no quiere números para los riesgos.

Por lo general, un administrador quiere saber que no arruinará el software.

Las dos áreas de riesgo equivalen a "¿sabes todo lo que necesitas saber?" y "¿romperás algo más?"

Probablemente debería hacer un análisis cualitativo de los riesgos.

Enumere las preguntas que tiene, las áreas misteriosas, las cosas que pueden requerir un seguimiento o que podría romper porque no las entiende.

Los "números" son 1.0. Tendrás cambios de seguimiento (hay siempre cambios de seguimiento) e introducirás nuevos errores previamente desconocidos (a menos que tengas una buena disciplina de prueba, lo que parece poco probable debido a la situación y la pregunta). ).

Lo ideal es que entiendas todo el problema y no necesites un seguimiento. ¿Es esto realmente cierto? ¿Qué evidencia puedes dar para que entiendas todo? Si tiene evidencia, preséntela y reclame que no hay riesgo de seguimiento. Si no tiene pruebas de que comprende todo el problema, haga una lista de las cosas que no entiende. Ese es el riesgo.

Idealmente, no romperás nada más. ¿Es esto realmente cierto? ¿Qué evidencia puedes dar para que tu cambio sea aislado y no rompas nada más? De nuevo, haz una lista de las cosas que podrían romperse; ese es el riesgo.

Tenga en cuenta que el conocimiento perfecto solo puede venir después de que haya completado todos los cambios. Solo después de que hagas el cambio de código, sabrás si lo sabías todo o no y no rompiste nada más.

Mirando hacia el futuro desconocido, solo puedes adivinar si sabes todo y no romperás nada.

En consecuencia, hay un nivel de rendimientos decrecientes. Puede proporcionar alguna evidencia de que entiende el cambio y no romperá nada, pero no puede estar absolutamente seguro de su análisis, excepto si realiza el cambio real del código.

    
respondido por el S.Lott 05.07.2011 - 12:56
4

El mejor lugar para comenzar sería con algunos ejemplos concretos. Elija algunas áreas de su aplicación y calcule el costo de que algo salga mal en esa área y la probabilidad de que suceda.

Por ejemplo, si realizó un cambio en el proceso de inicio de sesión, los costos podrían ser:

  1. Los usuarios no pueden iniciar sesión.
  2. Cualquier persona que pueda acceder.
  3. Los usuarios inician sesión pero no tienen acceso a la funcionalidad correcta, es decir, tienen la función incorrecta.

Luego se evalúa la probabilidad de cada uno:

  1. Es improbable: recogerá esto en las pruebas con bastante rapidez.
  2. Improbable: una vez más, esto es (o debería ser) fácil de recoger.
  3. Más probable: dependiendo de lo compleja que sea su aplicación para detectar que alguien tiene acceso a algo que no debería o no tiene acceso a algo que debería es más difícil de detectar.

Por lo tanto, la necesidad de "cambios en el código de seguimiento" y la "pérdida potencial de estabilidad" para los dos primeros es baja (pero seguirá existiendo), mientras que para el tercero es mayor.

Una vez que hayas hecho esto en algunas áreas de alto y bajo riesgo, podrás asignar cualquier cosa en una de estas áreas.

    
respondido por el ChrisF 05.07.2011 - 12:54
0

Aunque creo que la "Estimación de riesgos" es principalmente una mala métrica, es aún peor si se la da a un desarrollador, especialmente al desarrollador que estará trabajando. Su gerente también podría pedirle que haga sus propias pruebas de aceptación y también su propia revisión de código.

Si hay una forma correcta de hacer un análisis de riesgos para una tarea o característica, lo haría por algunas medidas:

  1. ¿Cuántos componentes independientes o puntos de función toca la característica?
  2. ¿Las características o componentes afectados tienen documentación de diseño o especificaciones técnicas claras y completas?
  3. ¿Hay funciones o componentes afectados cubiertos por las pruebas unitarias automatizadas?
  4. ¿Qué otras medidas de deuda técnica están estrangulando el sistema que podrían ser problemáticas?

Tal vez si puede tener en cuenta numéricamente este tipo de cosas y formularlas en algún tipo de foro de BS para determinar una proporción de riesgo, su gerente probablemente estará contento con eso. Fórmulas como la que describí, aunque en su mayoría sin sentido, son como Porno Gerencial.

    
respondido por el maple_shaft 05.07.2011 - 13:43

Lea otras preguntas en las etiquetas