Las mejores métricas actuales relacionadas con los requisitos, el diseño y la arquitectura

Así que mi jefe me planteó una 'investigación y averiguación':

  • ¿Hay ALGUNA (absolutamente alguna, no importa la más tonta, pero alguna) métrica para la gestión de requisitos? P.ej. Requerimientos de completitud, consistencia y productividad (siendo los más difíciles de precisar, es decir, qué se entiende por productividad).

Pregunta similar con respecto a las métricas de nivel de diseño y arquitectura. Es decir, existen y cuáles son si existen.

Es un poco confuso en este momento, pero quería saber cuáles son las métricas que ha usado comúnmente en estas etapas (si las ha usado) y qué ha encontrado que vale la pena. La noción es que la mayoría de las empresas pueden (y lo hacen) generar métricas patentadas para medir cosas relacionadas con las fases de requisitos/diseño/arquitectura, pero ¿existen algunas 'comúnmente aplicables'?

Nota : no estoy buscando métricas relacionadas con el código como complejidad ciclomática o errores/100 LOC o puntos de función

Soy consciente de la acumulación de productos en la comunidad ágil, junto con los gráficos de quemados de lanzamientos que tienden a darle una buena idea de las cosas, pero no funcionan tan bien en un entorno de estimación sin punto de historia, en mi opinión. Son buenos indicadores para medir los aspectos de consistencia, integridad y productividad de los requisitos antes mencionados, pero no están seguros de qué tan bien pueden satisfacer eso.

Soy muy consciente de que es un problema difícil, no estoy buscando una solución, sino meras opiniones/puntos de vista sobre lo que ha usado o visto/escuchado que se usa a este respecto. Las referencias de trabajos de investigación también son más que bienvenidas :)

No es un duplicado, pero es similar a ¿Cuáles son las buenas métricas para un SRS?
¡Sí! Había mirado eso. La mayoría de los textos dicen que se debe "rastrear" dichas métricas, mi pregunta es "qué métricas" han podido cuantificar esas ideas de manera concreta y cuál ha sido la experiencia de usarlas. P.ej. Es bueno que los requisitos no sean ambiguos, pero ¿hay alguna métrica (no importa cuán oscura, menos utilizada o tonta) que ayude a cuantificar la ambigüedad?
La mejor y única forma segura que conozco para garantizar que un requisito no sea ambiguo es documentar la metodología de verificación. No solo el método (por ejemplo, análisis, texto, inspección, etc.), sino una descripción detallada de lo que va a hacer exactamente y los criterios objetivos de aprobación/rechazo. De esa manera el significado del requisito es claro. Una vez que el sistema ha pasado por la metodología de verificación y ha pasado, eso es lo que significa cumplir con el requisito.

Respuestas (3)

En términos de métricas para un conjunto de requisitos:

  • la cantidad de requisitos es una buena indicación de la complejidad del sistema (puede parecer tonto al principio, ya que no todos los requisitos tienen el mismo "tamaño", pero en conjunto parece no funcionar peor que contar líneas de código para la complejidad del software)
  • número de TBX tanto en términos absolutos como en porcentaje de requisitos que aún no están completos. También puede ayudar a rastrear los diferentes sabores, ya que un TBD (determinado) es menos maduro que un TBR (resuelto/revisado) o un TBS (suministrado)
  • número de requisitos con métodos y metodologías de verificación , ya que los requisitos que nadie ha pensado en cómo verificar probablemente aún no sean tan buenos
  • cantidad de requisitos que fluyen hacia especificaciones de nivel inferior o, de manera similar, la cantidad de requisitos sin hijos en especificaciones de nivel superior o huérfanos en especificaciones de nivel inferior

Si está hablando de medir la eficiencia de sus procesos de gestión de requisitos:

  • horas cobradas por solicitud de cambio liberada
  • plan de quemado de verificación vs. progreso real
  • porcentaje de las especificaciones en el árbol de especificaciones que se publican y están bajo gestión de configuración
¡Bonito conjunto! Sugerí la cantidad de requisitos originales capturados para convertirlos en entregables finales, etc. Pero la pregunta era "¿hay algo en la literatura o deberíamos crear uno propio?" :) Y eso es lo que me hace rascarme la cabeza (y espero que la comunidad también :)
Si hay un cuerpo de literatura sobre métricas de requisitos, entonces no estoy al tanto, lo cual es completamente posible. Pero la mayoría de las grandes empresas que conozco han capturado y destilado su conocimiento institucional en procesos internos. Es decir, no me sorprendería que no pudiera encontrar nada en la literatura y decidiera que lo mejor que podía hacer era pensar si es suyo y capturarlo para uso futuro como lo han hecho otras compañías.
¡Absolutamente! Eso es "exactamente" lo que le dije a mi jefe :)

Aunque no se relaciona exclusivamente con la ingeniería de requisitos o las fases de diseño y arquitectura, la efectividad de la eliminación de defectos se puede utilizar para averiguar qué tan efectivas son sus actividades de ingeniería y diseño de requisitos, junto con todas las demás actividades a lo largo del ciclo de vida.

La idea es que cree una tabla que muestre dónde se encontraron los defectos, dónde se repararon y de dónde provinieron. Con esta información, puede averiguar cuántos defectos de requisitos se encontraron en los requisitos, en el diseño o se deslizaron hasta la implementación de campo. Puede realizar un seguimiento de esto por iteración (ya que cada iteración se ocupará de la ingeniería de requisitos hasta la implementación), así como por proyecto. Sin embargo, debe completar algunas iteraciones para tener suficiente información sobre la efectividad de sus prácticas en cada fase y hacer correcciones.

Otras medidas y métricas estarían relacionadas con las tasas de cambio de los requisitos, como los requisitos agregados, eliminados y modificados. Además, también podría ser adecuado relacionar los requisitos con el tiempo de implementación o la cobertura de la prueba. Sin embargo, creo que la respuesta de Adam Wuerl discute esto bastante bien .

¡Sí! ¡Lo hacemos muy bien actualmente! Esos son exactamente (y probablemente solo) los tipos de métricas que rastreamos... Estoy más interesado en encontrar otras más directas como mencioné en el OP
@Nupul La única otra cosa que encontré que podría ser interesante sería correlacionar la satisfacción del cliente con los requisitos. Probablemente haya algún tipo de vínculo entre "qué tan buenos son los requisitos" y "qué tan contentos están los clientes y usuarios con el software". Desafortunadamente, no pude encontrar ninguna investigación sólida en esta dirección. Tal vez mirar la investigación y los estudios sobre TQM podría arrojar algo en esta dirección, en realidad estoy un poco sorprendido por la falta de trabajo conocido y/o fácil de encontrar sobre las actividades posteriores y la calidad del software.
Totalmente de acuerdo en la dificultad de encontrar...

El modelo de estimación de costos de Revic 9.2 también estima los requisitos y las etapas de revisión. Tenga en cuenta, sin embargo, que se basa en líneas de código, por lo que es una estimación aproximada. Además, es un modelo de la Fuerza Aérea de EE. UU., por lo que está destinado a proyectos militares.

Las mejores métricas actuales relacionadas con los requisitos, el diseño y la arquitectura
RespuestasAquíPolítica de privacidad1y, 0v