SRS y otras razones por las que los proyectos de seguridad funcional pueden destacarse...

2017-12-15

Documentando la Seguridad Funcional de Sistemas Instrumentados

Farshad Nourai
NEXO: technology, risk, performance

Nos sentamos con una delegación de ingenieros del cliente durante toda la semana pasada en Dubai para revisar, evaluar o verificar su diseño de sistema HIPPS y documentación de seguridad funcional, es decir, SRS, plan de seguridad funcional, plan de verificación, procedimiento de gestión de configuración, etc. La reunión fue muy bien y los documentos estaban en muy buenas condiciones.
Nuestro socio Risknowlogy y nosotros hemos completado con éxito 5 proyectos de verificación y certificación de seguridad funcional en Irán en los últimos dos años, todos los cuales incluyeron la preparación de documentos como SRS y otros mencionados anteriormente. No hace falta decir que cada proyecto es único y plantea sus propios desafíos; y lecciones.

‘’Los documentos solo son útiles cuando son realistas, objetivos e integrados’’

¡Así que estaba tratando de generalizar sobre la fórmula mágica del éxito en tales proyectos…!

De hecho, más allá del contenido técnico de nuestras reuniones de la semana pasada, estaba tratando de ver el panorama general y extraer la anatomía de la documentación eficiente del proyecto desde el punto de vista de la gestión de la seguridad funcional para apoyar mejor el lado práctico del proyecto (¿o son mundos separados después de todo?). Aquí están, en mi opinión:

1. La documentación debe ser una representación REALISTA de un proyecto si va a ayudarte. Los términos clave aquí son: 'Oportuno' (los documentos deben prepararse de acuerdo con los hitos del proyecto para ser útiles en las etapas posteriores), 'Preciso' (no tiene sentido capturar solo la imagen general; adentrarse en detalles útiles y relevantes), 'Específico' (cada proyecto es diferente: diferentes clientes, diferentes listas de deseos, diferentes entornos y, por lo tanto, diferentes requisitos), y 'Cumplimiento' (IEC proporciona una lista de requisitos que deben seguirse pacientemente en los documentos y no todos son técnicos, una gran parte de ellos se trata de gestionar el proyecto: tu proyecto - abórdalos uno por uno). 

2. Los documentos deben ser OBJETIVOS: toma el ejemplo de un SRS, ¿por qué lo escribimos después de todo? ¿Es solo porque IEC 61511 nos lo pide? Los documentos deben ser objetivos porque (a) con un objetivo claro, escribir un documento se vuelve mucho más fácil y (b) los documentos objetivos se convierten en una herramienta útil para guiarte en lugar de una tarea adicional inútil que simplemente tienes que completar. Como otro ejemplo, considera un procedimiento FAT. El objetivo de un Procedimiento FAT es documentar las pruebas a realizar en el SIS en el taller. ¿Necesitas pensar en que una prueba se parezca lo más posible a una condición del mundo real, verdad? Entonces, ¿cómo lo haces? Simplemente escríbelo para cada prueba y listo. La recompensa es que un Procedimiento FAT bien pensado minimiza las sorpresas en el momento del FAT real y acelera tus tareas.
   

3. Los documentos deben ser INTEGRADOS (debes abordar y documentar interfaces entre tareas, subsistemas, requisitos, especificaciones, etc., y la dinámica del proyecto. Por lo tanto, debes verificar varios documentos de ida y vuelta y mediante comparaciones).
   

Entonces, ¿qué tiene de bueno todo esto? La conclusión es que si preparas tus documentos de esa manera, te asegurarás de haber abordado todos los factores importantes que afectan tu proyecto. Por lo tanto, significa que has mejorado la gestión de calidad del proyecto, y por lo tanto, sus resultados, así como tu conocimiento y experiencia. Además, hay muy buenas posibilidades de que puedas identificar áreas donde te falten información o datos. A veces te das cuenta de que tienes que coordinar algunos elementos con otras partes involucradas, como tu cliente, y eso te ahorra tiempo y dinero al evitar retrasos, retrabajos, responsabilidades, etc.

Los documentos son importantes porque son herramientas que pueden protegerte contra los riesgos del proyecto. ¡Hazte cargo de prepararlos bien!