PL.GC-2 REVISiÓN: 2 FECHA: JULIO DE 2007 ININ. instituto nacional de investigaciones nucleares COPIA NO CONTROLADA PLAN DE GARAN E SOFTWARE

Transcripción

1 REVISiÓN: 2 FECHA: JULIO DE 2007 ININ instituto nacional de investigaciones nucleares PLAN DE GARAN E

2 instituto nacional de investigaciones nucleares REVISiÓN: 2 FECHA: JULIO DE 2007 PLAN DE GARANTíA AD DE / SIIA.TIA / -' DI CILleAD I 11 I li PREPARADO POR: M. en C. Alejandro Arenas Ocho: ~.>: REVISADO POR: Ing. Félix Pablo Pérez Górnez. APROBADO POR: Ing. Marcelino Arnbriz Jaimes,~\.~< ~~ ".._).-J Ú <.9 L.L GARANTíA DE CALIDAD

3 PLAN DE DE HOJA: 1 ÍNDICE 1 OBJETIVO Y ALCANCE REFERENCIAS ADMINISTRACIÓN DOCUMENTACIÓN NORMAS, PRACTICAS, CONVENCIONES Y MÉTRICAS REVISIÓNES Y AUDITORÍAS PRUEBAS INFORME DE PROBLEMAS Y ACCIONES CORRECTIVAS HERRAMIENTAS, TÉCNICAS Y METODOLOGÍAS CONTROL DEL CÓDIGO CONTROL DE MEDIOS CONTROL DE SUMINISTROS RECOPILACIÓN, CONSERVACIÓN Y RETENCIÓN DE REGISTROS ENTRENAMIENTO ADMINISTRACIÓN DE RIESGOS NOTACIONES DEFINICIONES APÉNDICES... 13

4 PLAN DE DE HOJA: 2 1. OBJETIVO Y ALCANCE 1.1. OBJETIVO Establecer las medidas sistemáticas y planeadas para el desarrollo de software en el Instituto Nacional de Investigaciones Nucleares, con la finalidad de garantizar que el software desarrollado satisface los requerimientos especificados ALCANCE 2. REFERENCIAS Este Plan aplica a las etapas de especificación de requerimientos, diseño, implementación, pruebas e instalación de software crítico y no crítico que se desarrolle en el Instituto Nacional de Investigaciones Nucleares, bajo el Sistema de Garantía de Calidad. Este Plan de Garantía de Calidad de Software se aplica conjuntamente con las partes que se indiquen del Programa de Garantía de Calidad aplicable a los Servicios Científicos y Tecnológicos para la Central Laguna Verde IEEE Std Standard glossary of software engineering terminology 2.2. IEEE Std Standard for quality assurance plans 2.3. IEEE Std Standard for software configuration management plans 2.4. IEEE Std Standard for Software Test Documentation 2.5. IEEE Std Recommended practice for software requirements specifications 2.6. IEEE Std Standard for software verification and validation 2.7. IEEE Std Recommended practice for software design descriptions 2.8. IEEE Std Guide software configuration management 2.9. IEEE Std Standard for software user documentation IEEE Std Standard for developing software life cycle processes

5 PLAN DE DE HOJA: Programa de Garantía de Calidad Aplicable a los Servicios Científicos y Tecnológicos para la Central Nucleoeléctrica Laguna Verde, PR. GC-13, revisión 7, ININ, febrero Programa de aseguramiento de calidad del software de la GCN, PAG-14, revisión 2, CLV/CFE, septiembre ADMINISTRACIÓN 3.1. ORGANIZACIÓN A continuación se muestra el organigrama funcional para la aplicación del presente plan. AUDITOR DE GARANTÍA DE CALIDAD USUARIO GERENTE DE SISTEMAS JEFE DEL DEPARTAMENTO DE SISTEMAS INFORMÁTICOS RESPONSABLE DEL SERVICIO RESPONSABLE DEL CONTROL DE DOCUMENTOS RESPONSABLE DEL DESARROLLO DE RESPONSABLE DE LA REVISIÓN Y PRUEBAS 3.2. TAREAS La parte del ciclo de vida del software que cubre el presente plan es: especificación de requerimientos, diseño, implementación, pruebas e

6 PLAN DE DE HOJA: 4 instalación. Cada una de estas etapas será verificada y validada según corresponda, a través del Plan de Verificación y Validación de software 3.3. RESPONSABILIDADES Gerente de Sistemas. a) Realizar y documentar las revisiones gerenciales Jefe del Departamento de Sistemas Informáticos. a) Supervisar las actividades de desarrollo de software Responsable del Servicio. a) Coordinar las actividades de desarrollo de software. b) Revisar la Especificación de Requerimientos de Software Responsable del Desarrollo de Software. a) Elaborar el Plan de Administración de la Configuración de Software. b) Elaborar la Especificación de Requerimientos de Software. c) Identificar las áreas de riesgo que se presenten durante el desarrollo de software crítico. d) Elaborar la Descripción de Diseño de Software. e) Realizar código fuente y documentación de programa. f) Elaborar la Documentación de Usuario Responsable de la Revisión y Pruebas. a) Elaborar el Plan Verificación y Validación de Software. b) Realizar las actividades descritas en el Plan Verificación y Validación de Software. c) Realizar las pruebas al software. d) Elaborar el Reporte final de Verificación y Validación.

7 PLAN DE DE HOJA: Responsable del Control de Documentos. a) Recopilar, controlar, archivar y eliminar los documentos y registros generados durante las actividades de desarrollo de software Usuario. a) Establecer y proporcionar la clasificación del software al solicitar el servicio. b) Colaborar con el Responsable del Desarrollo en la elaboración de la Especificación de Requerimientos del Software. c) Realizar la evaluación 10 CFR50.59 cuando aplique. d) Participar en la elaboración del Plan de Verificación y Validación, cuando así aplique. e) Realizar las pruebas de aceptación, así como la certificación del producto final del software Auditor de Garantía de Calidad 4. DOCUMENTACIÓN. a) Verificar el cumplimiento del Plan de Garantía de Calidad de Software. b) Revisar procedimientos, planes o especificaciones que establecen el ciclo de vida del software OBJETIVO. Identificar la documentación a elaborar, durante el desarrollo del software REQUERIMIENTOS DE DOCUMENTACIÓN Especificación de Requerimientos de Software (ERS). En la ERS se describe con claridad y precisión los requerimientos esenciales (funciones, desempeño, restricciones de diseño y atributos) del software y sus interfases externas. Cada requisito

8 PLAN DE DE HOJA: 6 debe establecerse de tal manera que pueda ser verificado y validado objetivamente por medio de un método específico. La ERS se debe desarrollar conforme al procedimiento P.SI-1 Especificación de requerimientos de software, Revisión vigente, basado en la Norma IEEE Std Recommended practice for software requirements specifications Descripción de Diseño de Software (DDS). La DDS explicará y detallará cómo el software será construido para satisfacer las ERS. La DDS describirá los componentes y subcomponentes del diseño de software incluyendo las bases de datos y las interfases externas. La DDS puede ser preparada en un inicio como una versión preliminar y posteriormente puede ser complementada para producir un DDS detallado. La DDS se debe desarrollar conforme al procedimiento P.SI-2 Descripción de diseño de software, Revisión vigente, basado en la Norma IEEE Std Recommended practice for software design descriptions Plan de Verificación y Validación de Software (PVVS). El PVVS identificará y describirá los métodos (inspección, análisis, demostración o prueba) a ser usados para verificar que: a) Los requerimientos de la ERS han sido aprobados por la autoridad apropiada b) Los requerimientos de la ERS han sido implementados en el diseño expresado en la DDS. c) El diseño expresado en la DDS es implementado en el código fuente. d) Validar que el código, cuando es ejecutado, cumple con los requerimientos expresados en la ERS. El PVVS se debe desarrollar conforme al procedimiento P:SI-5, Verificación y Validación de Software, Revisión vigente, basado en la Norma IEEE Std Standard for software verification and validation Reporte de Verificación y Validación del Software (RVVS). EL RVVS describirá los resultados de la ejecución del PVVS.

9 PLAN DE DE HOJA: 7 El RVVS se debe desarrollar conforme al procedimiento P:SI-5, Verificación y Validación de Software, Revisión vigente, basado en la Norma IEEE Std Standard for software verification and validation Documentación de Usuario. La documentación de Usuario describirá y especificará los datos requeridos y el control de entradas, secuencias de entradas, opciones, limitaciones del programa y otras actividades o elementos necesarios para la ejecución satisfactoria del software. Todos los mensajes de error deben ser identificados, además, se deben proporcionar las instrucciones necesarias para ser corregidos. La documentación de Usuario, se debe desarrollar conforme al procedimiento P.SI-3 Documentación de Usuario, Revisión vigente, basado en la Norma IEEE Std Standard for software user documentation Plan de la Administración de la Configuración del Software (PACS). El PACS documentará los métodos a ser usados para la identificación de los elementos del software, control e implementación de cambios, control y registro del estado de la implementación de los cambios. El PACS se debe desarrollar conforme al procedimiento P.SI-4 Plan de administración de la Configuración de Software, basado en la Norma IEEE Std Standard for software configuration management plans. La documentación generada en los puntos a conforma el Apéndice 4.1. Documentos del Desarrollo de Software Documentación adicional Durante el desarrollo de software se puede incluir documentación adicional, tal como: plan de desarrollo de software, manual de procedimientos y normas, plan de la administración del proyecto de software, manual de mantenimiento del software, etc., cuando sean establecidas en el contrato.

10 PLAN DE DE HOJA: 8 5. NORMAS, PRACTICAS, CONVENCIONES Y MÉTRICAS Cuando se identifiquen para su aplicación normas, prácticas, convenciones y métricas en el desarrollo del software, las mismas serán incluidas en el Apéndice 5.1, su cumplimiento será verificado a través del PVVS. Como mínimo, la información siguiente será proporcionada: a) Estándares de la documentación; b) estándares de la estructura de la lógica; c) Estándares de la codificación; d) Estándares del comentario; e) Estándares y prácticas de prueba; f) Producto seleccionado de la garantía de calidad del software y métrica del proceso tal como: métricas de función; métricas de punto de decisión; métricas de dominio; métricas de mensaje de error y métricas de demostración de los requisitos 6. REVISIONES Y AUDITORÍAS OBJETIVO Definir las revisiones y auditorías técnicas y administrativas que serán llevadas a cabo. Así como establecer la manera en que las revisiones y auditorías son realizadas REQUERIMIENTOS MÍNIMOS Revisión de requerimientos de software. Esta revisión es realizada para asegurar que la ERS describe con claridad y precisión los requerimientos esenciales y que estos pueden ser verificados y validados objetivamente. La validación de la ESR y DDS, se realiza una vez que se tiene verificado el Código Fuente Revisión del diseño preliminar. Esta revisión es realizada para evaluar que el diseño preliminar contenga lo expuesto en la ERS, además de evaluar la consistencia técnica del diseño preliminar Revisión del diseño crítico.

11 PLAN DE DE HOJA: 9 Esta revisión es realizada para evaluar que el diseño crítico (también conocido como revisión del diseño detallado) contenga lo expuesto en la ERS, además de evaluar la consistencia técnica del diseño Revisión del plan de verificación y validación de software. Esta revisión es realizada para evaluar que los métodos de verificación y validación definidos en el PVVS son suficientes y completos, para demostrar que la ERS se satisface ampliamente. Las revisiones indicadas en los párrafos a deben ser realizadas por el Responsable de la Revisión y Pruebas e incluidas en el PVVS y sus resultados informados en el RVVS Auditorías. Las auditorías al desarrollo del software serán efectuadas por personal certificado de la Gerencia de Garantía de Calidad, bajo un programa de auditorías que dependiendo de la complejidad y etapa del trabajo a desarrollar, incluya la cantidad y tipo de auditorías que se requieran. Las Auditorías se desarrollan acorde a lo descrito en el criterio XVIII, Auditorías, del Programa de Garantía de Calidad PR.GC-13, revisión vigente Revisiones Gerenciales. Estas revisiones son efectuadas periódicamente por el Gerente de Sistemas, para valorar la ejecución de todas las acciones y los elementos identificados en el PACS. Las revisiones también pueden ser por una tercera parte competente, generando la evidencia documental correspondiente Revisión del Plan de la Administración de la Configuración del Software. Esta revisión se realiza para evaluar que los métodos de administración de la configuración definidos en el Plan de la Administración de la Configuración del Software son completos y suficientes.

12 PLAN DE DE HOJA: PRUEBAS Revisión al término del proyecto. Concluido el proyecto, se realiza la revisión para valorar el desarrollo de las actividades realizadas durante el proyecto y proporcionar las recomendaciones. Las revisiones indicadas en los párrafos y deben ser realizadas por el Responsable de la Revisión y Pruebas e incluidas en el PVVS y sus resultados informados en el RVVS. Todas las pruebas que deban ser aplicadas al desarrollo del software serán incluidas en el Plan de Verificación y Validación del Software. 8. INFORME DE PROBLEMAS Y ACCIONES CORRECTIVAS Estas actividades se deben realizar acorde a lo descrito en el PVVS. 9. HERRAMIENTAS TÉCNICAS Y METODOLOGÍAS Cuando se identifiquen herramientas especiales de software, técnicas y metodologías de soporte a la garantía de calidad del software, se establecerá su propósito y se describirá su utilización, lo cual deberá estar en el Apéndice CONTROL DEL CÓDIGO El control del código fuente debe ser documentado como parte del Plan de la Administración de la Configuración del Software. 11. CONTROL DE MEDIOS El control de medios debe ser documentado como parte del Plan de la Administración de la Configuración del Software. 12. CONTROL DE SUMINISTROS Esta actividad se debe realizar acorde a lo descrito en el criterio IV, Control de documentos de adquisición y el criterio VII, Control de materiales, equipos

13 PLAN DE DE HOJA: 11 adquiridos y servicios contratados, del Programa de Garantía de Calidad PR.GC- 13, revisión vigente. 13. RECOPILACIÓN, CONSERVACIÓN Y RETENCIÓN DE REGISTROS. Estas actividades se deben realizar acorde a lo descrito en el criterio XVII, Registro de garantía de calidad, del Programa de Garantía de Calidad PR.GC-13, revisión vigente. 14. ENTRENAMIENTO. El personal responsable de desarrollar software, será instruido en el objetivo, alcance y requerimientos del Plan de Garantía de Calidad del Software y los procedimientos aplicables, bajo un Programa de Capacitación y Adiestramiento. 15. ADMINISTRACIÓN DE RIESGOS. Se deben especificar los métodos y procedimientos empleados para identificar, evaluar, monitorear y controlar las áreas de riesgo que se presenten durante el desarrollo de software crítico cubierto por el presente Plan. En el Apéndice 15.1 se documenta el proceso de administración de riesgos. 16. NOTACIONES. CVS Ciclo de Vida del Software. SW Software. DDS Descripción el Diseño de Software. ESR Especificaciones de Requerimientos del Software. PVVS Plan de Verificación y Validación de Software. RVVS Reporte de Verificación y Validación de Software. PACS Plan de la Administración de la Configuración de Software.

14 PLAN DE DE HOJA: DEFINICIONES Administración de la configuración de software. Es la aplicación instrucciones técnicas y administrativas, y de supervisión para: Identificar y documentarlas características físicas y funcionales de los elementos de la configuración, control de cambios de esas características, control y registro de los cambios y su estado de implementación, y la verificación de su cumplimiento con los requerimientos especificados Auditoría. Examinación independiente del resultado o resultados del trabajo para evaluar el cumplimiento con especificaciones, normas, acuerdos contractuales u otros criterios Auditoría Física. Efectuada para verificar que los elementos de la configuración, así construidos, están conforme a la documentación que los define Auditoría Funcional. Efectuada para verificar que el desarrollo de los elementos de la configuración han sido completados satisfactoriamente, que los elementos han cumplido con las características funcionales y de desarrollo especificadas en la configuración funcional, y que su documentación de soporte y de operación es satisfactoria y completa Ciclo de Vida del Software: Periodo que comienza cuando un producto de software es concebido y finaliza cuando el software es retirado y no se usa más. Típicamente el CVS incluye una etapa de concepto, de especificación de requerimientos, de diseño, de implementación, de pruebas, de instalación, de operación, de mantenimiento y algunas veces la etapa de retiro Código fuente: Instrucciones de computadora y definición de datos expresados de forma adecuada para ser introducidos en un ensamblador, compilador u otro traductor.

15 PLAN DE DE HOJA: Competencia. Atributos personales y aptitud demostrada para aplicar conocimientos y habilidades Descripción del diseño del software: Es una representación del software producido para facilitar su análisis, planeación, implementación y la toma de decisiones. Un anteproyecto o modelo del sistema software. El DDS es usado como primer medio para comunicar la información del diseño de software Especificación de requerimientos de software: Documentación de los requerimientos esenciales (funciones, desempeño, restricciones de diseño y atributos) del software y sus interfaces externas Hardware: Equipo físico usado para procesar, almacenar o transmitir programas o datos de computadora Software: Programas de computadora, procedimientos, y cualquier documentación y datos asociados relativos a la operación de un sistema de cómputo Usuario: Organización o persona que opera o usa el software, ya adquirido o desarrollado Validación: El proceso de evaluación de un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface los requerimientos especificados Verificación: El proceso de evaluación de un sistema o componente para determinar si los productos de una determinada fase de desarrollo satisfacen las condiciones impuestas al inicio de ésta.

16 PLAN DE DE HOJA: APÉNDICES. APÉNDICE 4.1 Documentos del Desarrollo de software. APÉNDICE 5.1 Normas, prácticas, convenciones y métricas. APÉNDICE 9.1 Herramientas técnicas y metodologías. APÉNDICE 15.1 Proceso de Administración de Riesgos. Nota: Estos apéndices se generarán en el transcurso del desarrollo del software, debiendo quedar integrados cada uno en un expediente específico. En caso de no aplicar algún apéndice, se deberá justificar y documentar el motivo en el expediente correspondiente.

17 CONTROL DE REVISiÓN Y APROBACiÓN DE DOCUMENTOS TíTULO DEL DOCUMENTO: Plan de Garantía de Calidad de Software IDENTIFICACiÓN: ;j, / -1-./ ORIGINAL U V7~"--' ~~.a:«: PREPARADO POR: M. en C. Elvin:Ü"aytjn G. Ilng. Tonatiuh Rivera G. LIY 'y/...cha: Julio/2004 REVISADO POR: M. en ~ ~r":"'- 11\ H. lino. Ale andro Arenas O.'" ff FECHA: Julio/2004 REVISlgJ~ N 1 :> ) r PREPARADO POR: Dra. Elvira Gaytán G. /lnq.._.iqmtiuh ijjvero G. ~ FECHA: Febrero/2007 '" REVISADO POR: Dr. Javier Palacios H. :.~-_.-l.",e'-)... "_ :E:vn/'\~ Irebrero/2007 APROBADO POR: Ing. Marcelino Ambriz Jaimes \... l~ \. \. 1 Q" p:febrero/2007 DESCRIPCiÓN DE LA REVISiÓN: ~J )~~ Actualización del Plan de Garantía de Calidad de Software. REVISIÓN N 2,~fIL1 /1 I 1n1 D NIH GAIAN r1a r PREPARADO POR: M. C. ALEJANDRO ARENAS OCHOA /}If1 / '" f~ '" ULIO/ 2007 REVISADO POR: ING. FELIX PABLO PEREZ GOM~/ / ~A ~,,~.. l." ULIO/2007 APROBADO POR: ING. MARCELINO AMBRIZ JAIMEi JA<' ~ ~ ~, ULIO/2007 DESCRIPCiÓN DE LA REVISiÓN: ACTUALIZACION DEL PLAl/ DE G~~TIA DE CALIDAD DEL. REVISiÓN N 3 PREPARADO POR: REVISADO POR: APROBADO POR: DESCRIPCiÓN DE LA REVISiÓN: FECHA: FECHA: FECHA: PREPARADO POR: REVISADO POR: APROBADO POR: DESCRIPCiÓN DE LA REVISiÓN: REVISIÓN N 4 FECHA: "" FECHA: FECHA: ~