Normativa que aplica para: Desarrollo de software y

Presentación del tema: "Normativa que aplica para: Desarrollo de software y"— Transcripción de la presentación:

1 Normativa que aplica para: Desarrollo de software y
Programa Institucional de Garantía de Calidad Nuclear Normativa que aplica para: Desarrollo de software y Reportabilidad de incumplimientos 11 de septiembre 2012 Sala 27, 4°de 9:00 a 12:00 hrs. Gerencia de Calidad y Competitividad Preparado e impartido por: M.C. Margarita García Martínez / M.C. Leticia Colín Orozco

2 Objetivo y alcance Estándares IEEE Código 10CFR21 Comentarios
Contenido 1 Objetivo y alcance 2 Estándares IEEE 3 Código 10CFR21 4 Comentarios

3 Objetivo y alcance del adoctrinamiento
Dar a conocer los requisitos para establecer un plan de garantía de calidad para el desarrollo del software en el IIE y Conocer de que forma reportar los incumplimientos que afectan la seguridad. Alcance Estándares IEEE y guía reguladora 1.168 Código 10CFR21

4 Estándares de la IEEE Para el desarrollo de software, la CNLV considera la aplicación del estándar: IEEE Plan de Garantía de Calidad de Software (Standard for Software Quality Assurance Plans – SQAP). Además, también considera la aplicación de la guía reguladora: 1.168 “Verificación, validación, revisión y auditorías para programas de software utilizados en sistemas de seguridad de centrales nucleares” La CNLV cuenta con el documento PAG-14 para cubrir los requisitos de la IEEE-730

5 Estándares de la IEEE Repaso del estándar IEEE-730 1 Propósito
2 Doctos Ref. 3 Gestión 4 Documentación 8 Acciones Correctivas 7 Pruebas 6 Revisión del SW 5 Prácticas, métricas 9 Herramientas, técnicas, métodos 10 Control de medios 11 Control de proveedores 12 Registros 16 Cambios e historia 15 Glosario 14 Gestión de riesgos 13 Entrenamiento Son 16 requisitos en total.

6 Estándares de la IEEE Bibliografía de apoyo:
IEEE Glosario de términos de ingeniería de software IEEE-828 Planes de gestión de la configuración de software IEEE-829 Documentación de las pruebas de software IEEE-830 Prácticas recomendadas para especificación de requerimientos de software IEEE Diccionario de medidas para producir software confiable IEEE Guía para el uso del diccionario de medidas para producir software confiable IEEE-1012 Verificación y validación del software IEEE-1016 Prácticas recomendadas para descripciones de diseño de software IEEE-1042 Guía para la administración de la configuración del software IEEE-1058 Planes de gestión para proyectos de software IEEE-1063 Documentación de usuario del software IEEE-1074 Desarrollo de un proceso/proyecto de ciclo de vida de software IEEE-1219 Mantenimiento de Software

7 IEEE-730 Estructura organizacional Tareas Roles y responsabilidades
Quien (administra, diseña, desarrolla, prueba, valida y verifica) Tareas Roles y responsabilidades Recursos estimados SQAP Objetivo Alcance Uso intencionado Nombres de los ítems 1 Propósito 2 Doctos Ref. 3 Gestión 4 Documentación Requerimientos de software Diseño del software Resultados de verificación Resultados de validación Usuario: Instalación, Manuales Plan de gestión de la configuración Lista: Documentos políticas leyes Entre otros

8 IEEE-730 Pruebas no incluidas en los planes de verificación y validación Métodos utilizados Identificar estándares Documentación Diseño Codificación Comentarios Pruebas Mejores prácticas 5 Prácticas, métricas 6 Revisión del SW 7 Pruebas 8 Acciones Correctivas Definir las revisiones Programar las revisiones Ejecución de las revisiones Otras acciones que se requieren y como implementarlas y verificarlas Prácticas Para reportar Dar seguimiento Resolver problemas Establecer responsables

9 IEEE-730 Asegurar que el SW adquirido cumple con los requisitos establecidos Si se adquiere un desarrollo de SW, verificar que el proveedor tiene su propio SQAP Identificar herramientas: Control de versiones Control de tareas Técnicas y métodos para soporte del SQAP 9 Herramientas, técnicas, métodos 10 Control de medios 11 Control de proveedores 12 Registros Identificar la documentación del SQA que se debe conservar Establecer los métodos para obtener, guardar, respaldar y mantener los registros Establecer el tiempo que se deben conservar Establecer el control de los medios de respaldo Documentación para copiar y respaldar Protección contra acceso no autorizado, daños o degradación

10 IEEE-730 Listado de términos únicos parra el SQAP
Identificar las actividades de capacitación o entrenamiento necesarias para conocer el SQAP 13 Entrenamiento 14 Gestión de riesgos 15 Glosario 16 Cambios e historia Métodos y procedimientos para identificar, clasificar, monitorear y controlar áreas de riesgos que aparezcan durante el ciclo de desarrollo del SW Procedimientos para: Modificar el SQAP Mantener el histórico de los cambios Historia de cada modificación

11 Guía Reguladora 1.168 Verificación, validación, revisiones y auditorías para programas de software utilizados en sistemas de seguridad de centrales nucleares REVISIÓN 1, FEBRERO DE1994 Guía aprobada por la comisión de regulaciones nucleares de Estados Unidos (NRC) que permite utilizar métodos alternativos para realizar la verificación, validación, revisiones y auditorías a programas de software utilizado en sistemas de seguridad de plantas nucleares. Esta guía reguladora aprueba el uso de los siguientes estándares: IEEE , " Estándar IEEE para la verificación y validación del software ", IEEE ," Estándar IEEE para revisiones y auditorías de software”.

12 Guía Reguladora 1.168 La finalidad es asegurar mediante la garantía de calidad la conformidad de las prácticas basadas en la experiencia y aceptadas dentro de las diversas comunidades técnicas de desarrollo de software para uso en sistemas de seguridad. La guía establece su posición regulatoria para: Criticidad del software Confiabilidad del software Verificación y validación independiente Conformidad de los materiales Garantía de calidad Herramientas para el desarrollo de software Tareas de verificación y validación: auditorías, análisis y pruebas de regresión, evaluación de seguridad, evaluación de las pruebas, evaluación de la documentación del usuario Otros códigos y estándares

13 Guía Reguladora 1.168 Criticidad del software (IEEE-1012)
4 El elemento de software al ejecutarse produce consecuencias graves, tales como: pérdida de la vida, pérdida del sistema, pérdida económica o social. La mitigación no es posible. 3 El uso intencionado del elemento de software o del sistema no se llevó a cabo, causando consecuencias graves tales como: lesiones permanentes, degradación mayor del sistema, impacto mayor económico o social. Es posible la mitigación parcial o completa. 2 Una función intencionada del elemento de software no se realizó, causando consecuencias menores. Es posible la mitigación completa. 1 La función intencionada del elemento de software no se llevó a cabo causando consecuencias insignificantes. No se requiere la mitigación.

14 Guía Reguladora 1.168 Confiabilidad del software (IEEE-1012)
La tabla 1 del estándar IEEE-1012 establece las tareas de verificación y validación, entradas y salidas para un software confiable, divididas en: Gestión del esfuerzo de la verificación y validación (Proceso: Gestión) Adquisición del soporte para la verificación y validación (Proceso: Adquisición) Planeación de la verificación y validación (proceso: Proveedor) Concepto de verificación y validación (Proceso: Desarrollo) Requerimientos de la verificación y validación (Proceso: Desarrollo) Diseño de la verificación y validación (Proceso: Desarrollo) Implementación de la verificación y validación (Proceso: Desarrollo) Pruebas de la verificación y validación (Proceso: Desarrollo) Instalación y “checkout” de la verificación y validación (proceso: Desarrollo) Operación de la verificación y validación (proceso: Operación) Mantenimiento (proceso: mantenimiento)

15 Guía Reguladora 1.168 Verificación y validación independiente (Criterio I - Organización) El anexo C del estándar IEEE-1012 establece la definición de independencia de la verificación y validación en tres parámetros: Independencia Técnica Independencia de Gestión Independencia Financiera Y establece las 5 formas más prevalecientes que son: Formas Técnica Gestión Financiera Clásica (SW-4) I Modificada (SW-3) i Integrada Interna Embebida e Nota: I – Independencia rigurosa, i – Independencia condicional, e- Independencia mínima

16 Guía Reguladora 1.168 Conformidad de los materiales.
La guía acepta lo establecido en el código 10CFR50 Apéndice B en cuanto a los criterios: III “Control de diseño”, establece medidas para la selección y revisión de la conformidad de materiales, piezas, equipos y procesos esenciales para las funciones relacionadas con la seguridad de estructuras, sistemas y componentes. VII “Control del material adquirido, equipos y servicios”, establece medidas para asegurar que lo adquirido se ajusta a los documentos de contratación. Sin embargo, para la verificación de software pre-existente de sistemas de seguridad, que no ha sido verificado durante el desarrollo, se apoya con la guía “Criterios para computadoras digitales en sistemas de seguridad de plantas nucleares” y en la norma EPRI-TR “Directrices para la evaluación y aceptación de equipo digital comercial grado nuclear para aplicaciones de seguridad”, donde se puede obtener información detallada de procesos de aceptación de software pre-existente. medidas

17 Guía Reguladora 1.168 Garantía de Calidad.
El Criterio I identifica las funciones de control de calidad para: Asegurar que se establece un adecuado programa de garantía de calidad efectivamente ejecutado, y Verificar, por vigilancias, auditoría e inspección, que las actividades que afectan a las funciones relacionadas con la seguridad han sido realizadas correctamente. El Criterio XVII exige que se mantengan registros suficientes para proporcionar evidencia de las actividades que afectan a la calidad. El Criterio III exige que los cambios en el diseño estén sujetos a las medidas de control de diseño acordes con los aplicados en el diseño original. Además, la IEEE 1012 (en la cláusula 7.7.4) establece disposiciones relativas a los procedimientos de control, de verificación y validación o los necesarios para proporcionar evidencia de las actividades que afectan la calidad, deben mantenerse como registros de control de calidad.

18 Guía Reguladora 1.168 Herramientas para el desarrollo de software.
Establece lineamientos para el manejo de las herramientas utilizadas en el desarrollo del software de sistemas de seguridad de acuerdo con el estándar IEEE “IEEE Standard Criterios para Computadoras Digitales en sistemas de seguridad de las centrales nucleares de generación de energía” aprobado en la revisión 1 de la guía reguladora “Criterios para computadoras digitales en sistemas de seguridad de plantas nucleares” . El IEEE establece que las tareas de verificación y validación como atestiguamientos, revisión y las pruebas no son necesarias para las herramientas de desarrollo de software, a menos de que el software que se produce utilizando dichas herramientas esté sujeto a las actividades de verificación y validación , que se establecen en la guía para detectar los defectos introducidos por uso de dichas herramientas.

19 Guía Reguladora 1.168 Verificación y Validación.
La tabla 3 del estándar IEEE 1012, lista las tareas "opcionales" de “verificación y validación” y se describen más detalladamente en Anexo G . Estas tareas pretenden proporcionar una capacidad de “adaptación” al permitir que las tareas sean añadidas a un conjunto mínimo establecido para la verificación y validación de software crítico. El personal regulador considera la excepción de algunas de las tareas de esta lista como un estado opcional de los métodos aceptables de componentes necesarios para cumplir con los requisitos de los apéndices A y B de la 10CFR50, tal y como se aplica al software, con independencia de la organización para la verificación y validación.

20 Guía Reguladora 1.168 Verificación y Validación.
El personal regulador considera las tareas de auditorías, análisis de regresión y prueba, evaluación de seguridad, evaluación de pruebas y evaluación de la documentación de usuario como parte del conjunto mínimo de actividades de verificación y validación de software crítico a menos de que: Sean incorporadas en otras tareas de verificación y validación en el plan de verificación y validación de software o Se realizan fuera de la organización verificación y validación de software como parte o la totalidad de las obligaciones de alguna otra organización.

21 Guía Reguladora 1.168 Otros códigos y estándares.
Varias secciones de los estándares IEEE e IEEE hacen referencia a otros códigos y normas de la industria. Si una norma de referencia se ha incluido por separado en códigos reguladores, los licenciatarios y los solicitantes deben cumplir con esa norma como se establece en el código regulador. Si la norma de referenciada ha sido endosada a una guía reguladora, la norma constituye un método aceptable para el organismo regulador para cumplir con un requisito reglamentario como se describe en la guía reguladora. Si una norma de referencia no ha sido endosada en algún código regulador ni en una guía reguladora, los licenciatarios y los solicitantes podrían considerar y utilizar la información de la norma referenciada, justificándola debidamente, de acuerdo con la práctica actual de los códigos y guías reguladoras.

22 Guía Reguladora 1.168 Independencia Técnica Independencia de Gestión
Participa personal que no está involucrado en el desarrollo del software. Este método es muy útil para detectar los errores sutiles pasados por alto por los que se encuentran haciendo el desarrollo de software. Herramientas de software: utiliza o desarrolla su propio conjunto de pruebas y realiza el análisis por separado de las herramientas de los desarrolladores. Independencia de Gestión La responsabilidad de la verificación y validación independiente residirá en una organización independiente de la organización de desarrollo y gestión de programas. Se debe permitir que esta organización independiente presente su programa de gestión, anomalías, resultados y conclusiones sin ningún tipo de restricción o presiones adversas, directa o indirectamente desde el grupo de desarrollo. Independencia Financiera El control del presupuesto de la verificación y validación independiente recae en una organización independiente a la de desarrollo. Evita situaciones en donde no se pueda completar el análisis o probar o entregar resultados a tiempo debido a la insuficiencia de fondos.

23 PAG-14 Programa de aseguramiento de la calidad de software de la GCN
Propósito: Establece los lineamientos para implementar un PAG de Software en la Gerencia de Centrales Nucleoeléctricas (GCN). Proporciona un método para asignar el nivel de calidad al software controlado por este procedimiento. El alcance incluye al software y al firmware clasificado como Relacionado con Seguridad, Importante para la Seguridad, Regulatorio y de Confiabilidad.

24 Código 10CFR21 Reporte de defectos e incumplimientos
Para establecer los conceptos de este código. Riesgo sustancial para la seguridad. Significa una pérdida de la función de seguridad a tal grado que provoque una reducción importante en el grado de protección a la salud pública y seguridad para cualquier instalación o actividad licenciada o de alguna manera aprobada o reguladas por la CNSNS. Establecer los lineamientos para que el responsable de una instalación de energía nuclear licenciada, reporte defectos o incumplimientos al organismo regulador. 1 Propósito 2 Alcance 3 Definiciones 4 Interpretación Individuo, sociedad, corporación u otra entidad: Titular de licencia o permiso para operar Que construye una instalación Que suministra elementos para certificación de diseño Tenencia de un diseño estándar Deben estar por escrito Autorizadas por el organismo regulador No se aceptan interpretaciones no escritas

25 Código 10CFR21 Reporte de defectos e incumplimientos
Siempre y cuando no se ponga en peligro la vida, la propiedad, la defensa y seguridad común. Reportes y comunicaciones por escrito con el organismo regulador. 5 Comunicación 6 Requisitos para publicar 7 Excepciones 8 Recopilación de información Requisitos para la reducción de trámites en la recopilación de información Lineamientos para publicar este código de regulación y otros procedimientos relacionados u obtener copias debidamente autorizadas

26 11 Inspecciones y registros
Código 10CFR21 Reporte de defectos e incumplimientos Permite al organismo regulador inspeccionar los registros. Requisitos para el mantenimiento e inspección de registros De incumplimientos o de la existencia de un defecto y su evaluación 9 Notificación 10 Documentos de compra 11 Inspecciones y registros 12 Aplicación Asegurarse de que en los documentos de compra se considere el cumplimiento del código 10CFR21. Al notificar una falla establece: Multa civil Sanción civil Veredictos

27 Comentarios En el IIE se está integrando el procedimiento P-GCN-020 “Procedimiento de aseguramiento de la calidad del software del IIE”, cuyo alcance es a proyectos importantes para la seguridad.

28 Gracias por su atención
Calidad no es un objetivo, es un compromiso permanente Gerencia de Calidad y Competitividad Instituto de Investigaciones Eléctricas Reforma No.113. Col. Palmira Cuernavaca, Morelos, México (777) ext. 7649