La importancia de los casos de uso en la validación funcional de un software

21 May La importancia de los casos de uso en la validación funcional de un software

La primera cuestión que una persona ajena al mundo de la auditoria de software sería ¿para que necesito validar funcionalmente un software? Desde mi experiencia, lo que me demandan mis clientes, las principales razones serian:

1. Validación de una aplicación, web, etc para obtener una ayuda o subvención. Ver mi articulo https://luisvilanova.es/servicios-de-evaluacion-y-auditoria-tecnologica-para-red-es-andalucia/
2. Implantación de un software en una empresa (por ejemplo, un ERP, un CRM…). La empresa cliente necesita validar que el desarrollo que está realizando un partner se adecua a sus necesidades.
3. En caso de juicio, como perito informático, la necesidad de validar el funcionamiento de un proyecto es crucial para aclarar ante el juez esta necesidad. En este sentido, por ejemplo, en mi web de peritajes informáticos https://www.leyesytecnologia.com podrá ver artículos al respecto.

Lejos de querer ser un purista o teórico, para mi forma de trabajo los casos de uso son una metodología formal pero práctica de evaluar funcionalmente un software. Quizás la razón más importante es que en su concepción mediante metodología UML, un caso de uso puede ser entendido por un profano en la informática. Dicho de otro modo cualquier usuario puede entender un caso de uso descrito con diagramas UML.

¿Qué es un caso de uso UML? Un caso de uso descrito con UML, para profanos, es la descripción escrita de una funcionalidad concreta que un programa debe proporcionar al usuario. Para que todo el que está leyendo este articulo lo entienda, esta descripción escrita se acompaña de diagramas que dejan muy claro la funcionalidad que el programa debe proporcionar en cada punto concreto.

Por ejemplo, un caso de uso podría ser dar de alta la cabecera de un pedido de compra en un portal ERP. En este ejemplo de caso de uso descrito con UML se incluiría:

• Nombre del caso de uso: Alta de la cabecera de un pedido de compra.
• Usuario del departamento de compras.
• Descripción breve: El sistema permitirá crear un pedido de compra a un proveedor externo.
• Precondiciones: El usuario tiene que haber realizado login y con permisos para realizar la operación, así como el proveedor y los artículos a solicitar correctamente dados de alta en el sistema.
• Flujo básico:
  1. El usuario realiza login y accede a la opción Crear pedido.
  2. El usuario selecciona el proveedor, asignando el sistema automáticamente los datos informativos del mismo, así como la fecha de creación del pedido.
  3. El sistema asigna a la cabecera del pedido los descuentos globales pactados con el proveedor.
  4. El sistema asigna el modo de pedido por email.
  5. El usuario dispone de un campo Observaciones donde puede rellenar información extra.
  6. El sistema asigna el tipo de pedido a Normal.
  7. El sistema asigna el estado ‘Pendiente’ a la cabecera de pedido recién creada.
  8. La cabecera queda grabada y podrá ser editada posteriormente.
  9. Al grabar el sistema le da acceso a crear las líneas del pedido.
• Flujo alternativo:
  • 4a. El usuario decide cambiar el modo de envío a fax.
  • 6a. El usuario puede cambiar el tipo de pedido a Urgente.

Es evidente que solo es un ejemplo para que el lector pueda comprender el alcance. Esta descripción del caso de uso se debe complementar con diferentes diagramas, que no incluiré en este post por su complejidad, como son:

• Diagramas de Estado.
• Diagramas de Interacción.
• Diagramas de Secuencia.

Para mí 3 de los diagramas más visuales e intuitivos que ayudan a formalizar, entender y validar en una auditoria la funcioanlidad esperada de un software.

Espero le haya aclarado parte de la metodología de validación de software que personalmente utilizo.

Luis Vilanova Blanco. Auditor y perito judicial informático.

606954593

luis@luisvilanova.es