Conexión entre requisitos y código en código

Estoy buscando una manera simple de conectar información sobre requisitos / publicación y código fuente. El caso es que el desarrollador debe ser capaz de encontrar cualquier artefacto creado en una versión dada o CR de forma sencilla. La idea que tengo es introducir una nueva anotación para marcar cualquier nueva class (no estoy seguro si es bueno para cualquier método nuevo), por ejemplo:

@ArtifactInfo(release="1.2" cr="cr123") 

¿Tienes alguna otra idea? Tal vez ya usas algo similar?

Cuídate, Marcin

IMO el código es el lugar equivocado para ese tipo de información.

Eche un vistazo al código imaginario a continuación.

 class Authenticator { login(String username, String password){ User user = retrieveUserFromDatabase(username); throwIfWrongpassword(user, password); verifyUserAge(user) } void throwIfWrongpassword(User user, String password){ //throws AuthenticationException if password is wrong } void verifyUserAge(User user){ //verify that user is above 18 or account is authorized by a parent } void biometricLogin(String username, BiometricImage bioimg){ User user = retrieveUserFromDatabase(username); verifyBiometricImage(user, password); verifyUserAge(user); } } 

Este es el resultado de algunos requisitos:

  • Los usuarios deben autenticarse para tener acceso al sistema
  • Los usuarios pueden usar la authentication biométrica en lugar de la authentication de contraseña
  • Los usuarios menores de edad deben ser autorizados ser padres o algo así.

Todos esos requisitos se agregaron en diferentes períodos de time, en diferentes versiones del software. Una anotación de nivel de class, o incluso de nivel de método, no será suficiente para asignar efectivamente los requisitos al código. Tendría que usar una anotación de nivel de "línea de código". Por supuesto, eso no es práctico.

La forma correcta de hacerlo es seguir algunas buenas prácticas al usar el repository de código fuente y el rastreador de errores:

  • 1) Cada requisito corresponde a uno o más problemas en el rastreador de errores
  • 2) Cada post de compromiso comienza con una key de problema correspondiente, como "PROJ-123 – una buena característica"
  • 3) Cuando haces un lanzamiento (es decir, incrementando tu versión de software), le dices al rastreador de errores que esos problemas fueron arreglados en esa versión.

Si necesita saber qué requisitos se implementaron en qué versión, pregunte a su rastreador de errores.

Si necesita saber todo el código que se produjo para un requisito determinado, pregunte en el repository de código fuente (filter confirma por post de logging)

Si necesita saber cuál es el requisito para una determinada línea de código, pregunte en el repository de código fuente. GIT y SVN tienen un command "culpar" que le indicará, para un file determinado, para cada línea de código, quién lo hizo, cuándo y el post de confirmación (que tendrá el número de problema si todos en el equipo son buenos chico) – Entonces esto funcionará como esa hipotética anotación de nivel de "línea de código".

El uso de "commit hooks" puede ayudarlo a aplicar la regla 2) en una organización.

Maven tiene cierto grado de integración con JIRA y otros rastreadores de errores, y tal vez puede ayudar a automatizar el # 3. Pero realmente no lo he usado así. Pero si no hace lo que necesita, siempre puede pedir más 🙂