(Círculo de LabVIEW: Parte 3 de 6)
Este es Círculo de LabVIEW: Requisitos, la tercera de una serie de entradas de blog que describen las diferentes etapas del ciclo de vida del proyecto LabVIEW desde la idea hasta el mercado. Aunque leerlos en orden ayudará a entender el panorama general, cada entrada del blog es independiente con una pequeña sección sobre el "RT Installer", una especie de producto de muestra utilizado en esta serie.
Esta entrada del blog pretende describir el proceso que tiene lugar en torno al momento en que se licita y adjudica un proyecto; se centra en el proceso de generación de requisitos que pueden utilizarse para captar el alcance del proyecto y verificarse posteriormente.
Una vez que hemos hablado con un cliente y establecido un alcance aproximado, tenemos suficiente información para generar una estimación en términos de tiempo y presupuesto y generar una propuesta. Afortunadamente , el proyecto está fuera del "purgatorio de proyectos", pero la propuesta no es suficiente para verificar que el producto o proyecto funciona.
No hay una forma objetiva de saber si este proyecto o producto funciona como se esperaba durante la fase de concepción; para resolver ese problema, creamos un documento llamado Documento de Requisitos del Sistema. Lo que hace este documento es refinar o centrar el alcance, identificando los puntos clave de la funcionalidad, explicando cómo deben funcionar las cosas dadas determinadas circunstancias y, lo que es más importante, una lista de requisitos verificables que pueden utilizarse para comprobar la funcionalidad.
Un requisito traduce las expectativas y el alcance del cliente en requisitos técnicos que pueden utilizarse para planificar el desarrollo de software y, posteriormente, durante las pruebas de aceptación del software, para verificar objetivamente la funcionalidad. La mejor manera de describir un buen requisito es que sea conciso, atómico, único y verificable.
A continuación se ofrecen algunos ejemplos de requisitos:
- Si la presión (PT-001) es superior al límite de sobrepresión (LIM-001), el software activará la alarma de sobrepresión (ALM-001).
- El software puede controlar la bomba manual y automáticamente
Analicemos ahora ambos ejemplos:
Por si no es obvio, el primer requisito es bueno porque es atómico; sólo describe una funcionalidad, mientras que el segundo describe dos. El primer requisito es muy conciso. Dice a qué presión se refiere, a qué límite se refiere y a qué enclavamiento se refiere; no hay ambigüedad.
En cambio, el segundo requisito no indica qué significa manual, automático o control. Por lo general, es imposible verificar el requisito 2.
Los buenos requisitos pueden utilizarse para planificar el desarrollo de software. Por ejemplo, el requisito 1 anterior puede utilizarse para generar las siguientes tareas a completar durante el desarrollo:
- Adquirir la corriente (PT-001) utilizando un dispositivo de adquisición de datos
- Utilizando ganancia/desplazamiento convertir PT-001 de mA a unidades de ingeniería
- Crear una lógica que pueda comparar PT-001 en unidades de ingeniería con el límite de sobrepresión (LIM-001) y disparar la alarma de sobrepresión (ALM-001)
El requisito puede verificarse ajustando el límite de sobrepresión a un valor conocido, provocando a continuación que la presión sea superior a dicho límite y confirmando que se dispara el enclavamiento. Una vez definidos los requisitos, es seguro empezar a desarrollar el software, ya que se tiene un alcance claro.
Una vez finalizada la prueba de concepto del "RT Installer", quisimos elaborar un documento de requisitos que recogiera el alcance previsto y nos proporcionara algo que pudiéramos utilizar para verificar la funcionalidad durante y después del desarrollo del software.
Consulta este PDF de 20 páginas del documento de requisitos elaborado para el "RTInstaller":
