COPIA NO CONTROLADA. ININ No: P.SI-5 Rev.: 2 Fecha de Emisión: Ago de 2010 Hoja: 1 de: 22. FIRMA1kW~ ~ ~~~ftl/v2

Transcripción

1 I Procedimiento: Area: Departamento de Sistemas Informáticos Verificación y Validación de Software ININ No: P.SI-5 Rev.: 2 Ago de 2010 Hoja: 1 Índice Página 1. OBJETIVO Y ALCANCE OBJETIVO ALCANCE NOTACIONES Y DEFINICIONES NOTACIONES DEFINICIONES DESARROLLO PROCESO CONTENIDO RESPONSABILIDADES REFERENCIAS ANEXOS \.{...,- {. GARANTIA DE CALIDAD DOCUMENTO VERIfiCADO Y LIBERADO POR: V.GC.9:r '15 (LAVE FE A. FIRMA1kW~ ~ ~~~ftl/v2 Preparado por: M.en C. David Valdivia Rosas ~ / Fecha: Agosto 2010 Revisado por: M. en C. Alfonso Villarreal Martínez~v~//// 21,( -///Á / M Fecha: Agosto 2010 Aprobado por: M. en C. José Luis Angeles V~s {/ ----',..- - Fecha: Agosto 2010

2 Hoja: 2 1 OBJETIVO Y ALCANCE 1.1 OBJETIVO El objetivo de este documento es proveer una guía para la elaboración de la planeación y documentación de las actividades requeridas, para realizar las actividades de Verificación y Validación de los productos de desarrollo del software. 1.2 ALCANCE Este procedimiento se aplica a software desarrollado bajo el SGC del ININ por personal del Departamento de Sistemas Informáticos de la Gerencia de Sistema. Este procedimiento está considerado como Norma Interna de Administración al estar relacionado con el tema de Tecnologías de la Información, de conformidad con el Sistema de Mejora Regulatoria Interna del Programa de Mejora de la Gestión de la Administración Pública Federal NOTACIONES Y DEFINICIONES 2.1 NOTACIONES DDS ERS GS ININ Norma PAC PVV RVV SI SGC VV Descripción de Diseño de Software Especificación de Requerimientos de Software Gerencia de Sistemas Instituto Nacional de Investigaciones Nucleares IEEE std Plan de Administración de la Configuración. Plan VV de Software Reporte final de VV del Software Departamento de Sistemas Informáticos Sistema de Garantía de Calidad Verificación y Validación

3 Hoja: DEFINICIONES Anomalía Cualquier cosa observada en la documentación o en la operación del software que se desvía de expectativas base del producto de software previamente verificados o los documentos de referencia Caso de prueba Un conjunto de entradas de prueba, de condiciones de ejecución, y de resultados previstos desarrollados para un objetivo particular, por ejemplo para realizar una trayectoria particular del programa o para verificar conformidad con un requisito específico. Documentación que especifica entradas, resultados previstos, y una serie de condiciones de ejecución para un elemento de la prueba Componente Una de las piezas que integra un sistema. Un componente puede ser hardware o software y puede estar subdividido en otros componentes Descripción del diseño del software (DDS) Una representación de un sistema de software creada para facilitar el análisis, planeación, implementación, y toma de decisiones. Un esquema o modelo de un sistema de software. La DDS es empleada como medio primario para comunicar información de diseño de software Diseño de la prueba Documentación que especifica los detalles del enfoque de la prueba para identificar una característica del software o combinación de características del software y las pruebas asociadas Elemento Un componente (Diseño, especificaciones, código fuente, documentación, conjunto de pruebas, manuales de procedimientos, etc) que se ha diseñado para el uso en contextos múltiples Entradas requeridas El conjunto de elementos necesarios para realizar las tareas mínimas de VV dentro de cualquier actividad del ciclo de vida

4 Hoja: Especificación de requerimientos del software (ERS) Documentación de los requerimientos esenciales (funciones, rendimiento, restricciones del diseño, y cualidades o atributos) del software y de sus interfases externas Especificación de requerimientos de la interfase Documentación que especifica los requerimientos para las interfases entre los sistemas y los componentes. Estos requerimientos incluyen restricciones sobre formatos Procedimiento de prueba Instrucciones detalladas para la disposición, la ejecución, y la evaluación de los resultados para un caso dado de prueba. Un documento que contiene un conjunto de instrucciones asociadas. Documentación que especifica una secuencia de las acciones para la ejecución de una prueba Procesos del ciclo de vida Conjunto de actividades correlacionadas que dan lugar al desarrollo o la evaluación de los productos de software. Cada actividad consiste en tareas. Los procesos del ciclo de vida pueden traslaparse uno con otro. Para los propósitos de VV, no se concluye ningún proceso hasta que sus productos del desarrollo se verifican y se validan según las tareas definidas en el PVV Prueba de aceptación Prueba formal conducida para determinar si o no, un sistema satisface sus criterios de aceptación y permitir al usuario determinar si o no aceptar el sistema. Prueba formal conducida para permitir al usuario determinar si aceptar un sistema o un componente Prueba de componente Prueba de los componentes individuales del hardware o de software o de un grupo de componentes relacionados Prueba de integración Prueba en la cual los componentes de software, los componentes de hardware, o ambos se combinan y se prueban para evaluar la interacción entre ellos.

5 Hoja: Prueba del sistema Prueba conducida en un sistema completo, integrado para evaluar la conformidad del sistema con sus requerimientos especificados Salidas requeridas El grupo de elementos que se producen como resultado de realizar las tareas mínimas de VV de cualquier actividad del ciclo de vida Sistema Una colección de componentes organizados para lograr una función o un conjunto de funciones Software Programas de computadora, procedimientos, reglas y cualquier documentación asociada y datos relativos a la operación de un sistema de computadora Tareas mínimas Tareas de VV requeridas para el nivel de la integridad de software asignado al software que se verifican y validan Tareas opcionales Tareas de VV aplicables a todos los desarrollo de software Usuario Organización, persona o personas que definen los requerimientos, operan o interactúa directamente con el software Validación El proceso de evaluación un sistema o componente durante o en el final del proceso del desarrollo para determinarse si satisface los requerimientos especificados Verificación El proceso de evaluar un sistema o componente para determinar si el producto de una determinada fase de desarrollo satisface las condiciones impuestas al inicio de esa fase.

6 Hoja: 6 3 DESARROLLO 3.1 PROCESO El proceso a seguir para la elaboración del PVV se indica en forma grafica en el anexo I, y se describe a continuación Preparar el PVV El revisor designado por el Jefe del Departamento de Sistemas Informáticos prepara el PVV conforme a este procedimiento Revisión del PVV a) El Jefe del Departamento de Sistemas Informáticos Revisar que el PVV se apegue a este procedimiento. b) En caso de existir observaciones, éstas se turnan al responsable de elaborar el PVV, para su aplicación Aprobación del PVV 3.2 CONTENIDO Una vez completo el PVV realizando las correcciones pertinentes, éste se envía a la GS para su aprobación. El Contenido del PVV se documenta en el formato PDF, empleando las formas FP.SI-01/0/4, FP.SI-02/0/4 y FP.SI-03/0/4 descritas en los anexos II, III y IV del procedimiento P.SI-4, Plan de Administración de la configuración Revisión Vigente. El contenido del PVV es el siguiente: 1. Introducción 1.1 Propósito 1.2 Alcance 1.3 Definiciones 1.4 Acrónimos 1.5 Referencias 1.6 Resumen 2. Administración del proceso de VV

7 Hoja: Organización 2.2 Programa de desarrollo 2.3 Responsabilidades 3. Proceso de Verificación y validación 3.1 VV de Requerimientos 3.2 VV del Diseño 3.3 VV de la Implementación 3.4 VV de pruebas 3.5 VV de Instalación 4. Reportes de VV 4.1. Reporte de tareas Reporte de resultados de tarea 4.3 Reporte de anomalías 4.4 Reporte Final 5. Requerimientos Administrativos de VV 5.1 Reporte y Resolución de Anomalías 5.2 Políticas de Interacción de Tareas 5.3 Políticas de Desviación 5.4 Procedimiento de Control 5.5 Estándares y Convenciones 6. Anexos A continuación se describe cada uno de los puntos del contenido del PVV Introducción En la sección uno del PVV, que es la introducción del documento, se debe especificar el propósito, el alcance, así como las definiciones y los acrónimos. a) Propósito (Sección 1.1). Dentro de la sección uno del PVV, como primer punto, se debe mencionar el propósito específico del Plan de Verificación y Validación de Software, en donde se establezca un marco común para los procesos, las actividades, y las tareas de VV de los procesos del ciclo de vida del desarrollo de software. b) Alcance Dentro de la sección uno (subsección 1.2) del PVV se debe mencionar los alcances del Plan de Verificación y Validación en donde se: i) Definan las tareas de VV, las entradas y salidas requeridas. ii) Identifiquen las tareas mínimas de VV. iii) Defina el contenido del Plan de VV del Software (PVV)

8 Hoja: 8 c) Definiciones (Sección 1.3). En esta sección se deben definir o dar una referencia para las definiciones de todos los términos requeridos para poder interpretar adecuadamente el plan, listadas en orden alfabético. d) Acrónimos (Sección 1.4). En esta sección, se deben de describir los acrónimos y notaciones necesarios para entender el PVV. Listados en orden Alfabético. e) Referencias (Sección 1.5) En esta sección, se deben identificar los documentos referenciados por dicha planeación y cualquier documento de apoyo para la implementación de la planeación. Esta sección de la PVV debe contener los siguientes datos: Titulo, identificación, número de revisión, editor y fecha de emisión. f) Resumen (Sección 1.6 del PVV).Describe brevemente el contenido de las secciones 2, 3,4 y 5 del PVV Administración del proceso de Verificación y Validación (Sección 2 del plan). En donde se debe describir la organización, la programación y las responsabilidades para realizar la VV del software. a) Organización (Sección 2.1 del plan). En esta sección se debe describir la organización del grupo de Verificación y Validación. Esta organización debe indicar las relaciones con otras tareas del proyecto, como el grupo de desarrollo, la administración o el usuario final. Además se deben definir las líneas de comunicación con el grupo de verificación y validación. b) Programa de desarrollo. (Sección 2.2. del plan). Está sección debe describir el ciclo de vida del proceso de VV y los puntos de revisión, incluyendo fecha en las cuales se llevarán a cabo. Este programa resume las tareas de VV. El plan de

9 Hoja: 9 trabajo se realiza en Project, en cualquier otro paquete o en un formato para hacerlo en forma manual. Cuando se planean tareas de VV se deben de organizar con la idea de que el proceso de VV sea interactivo. c) Responsabilidades. (Sección 2.3. del plan). En está sección se debe de indicar las responsabilidades de los elementos de la organización para cada tarea de VV. En ésta sección se debe resumir los roles y responsabilidades definidas en cada secciones de la fases del ciclo de vida del PVV Proceso de Verificación y Validación. (Sección 3). En esta sección se detalla el plan para las etapas de VV, y se deben considerar los siguientes puntos para cada etapa de VV: a) Tareas de VV de la fase b) Métodos y procedimiento c) Documentos de entrada d) Documentos de salida e) Programación f) Recursos g) Roles y responsabilidades. a) Verificación y Validación de Requerimientos (Sección 3.1). La verificación y la validación de los requerimientos trata el análisis de los requerimientos del software, funcionales y de rendimiento, de las interfases externas al software, y de los requerimientos para la calificación y la seguridad, la ingeniería de factores humanos, las definiciones de los datos, la documentación del usuario del software, la instalación y la aceptación, la operación del usuario. El planeamiento de la prueba de la validación y verificación comienza durante la actividad de la verificación y validación de los requerimientos y atraviesa varias actividades de VV. La VV de los requerimientos incluyen las tareas siguientes. i) Tarea: Análisis de seguimiento de los requerimientos de software. En la forma FP.SI-1/0/5 (anexo II). ii) Tarea: Evaluación de los requerimientos del software. iii) Tarea: Análisis de la interfaz de requerimientos de software. iv) Tarea: Generación del plan de prueba de VV del sistema. v) Tarea: Generación del plan de prueba de VV de la aceptación.

10 Hoja: 10 b) Verificación y Validación del Diseño (Sección 3.2) En el diseño del software, los requerimientos del software se transforman en una arquitectura y un diseño detallado para cada componente de software. El diseño incluye las bases de datos y las interfases de sistema (ejemplo, hardware, operador, usuario, componentes de software, y subsistemas). La actividad de la VV del diseño contempla el diseño arquitectónico y el diseño detallado del software. El planteamiento de las pruebas de VV continúa durante la actividad de la verificación y validación del diseño. El objetivo de la VV del diseño es demostrar que el diseño es una transformación correcta, exacta, y completa de los requerimientos del software y que no se introducen ningunas características involuntarias. Incluye las siguientes tareas: i) Tarea: Análisis de seguimiento del diseño. Forma FP.SI-1/0/5 (anexo II) ii) Tarea: Evaluación del diseño del software. iii) Tarea: Análisis de las interfases del diseño. iv) Tarea: Generación del plan de pruebas de componentes v) Tarea: Generación del plan de prueba de integración vi) Tarea: Generación del diseño de la pruebas de: Componentes Integración. Sistema. aceptación. c) Verificación y Validación de la Implementación (Sección 3.3 del PVV). En la implementación del software, el diseño del sistema se transforma en código, la estructura de la base de datos, y contar con el programa ejecutable de la máquina. La VV de la implementación está dirigida a la codificación del software y prueba, incluyendo la incorporación de los productos de software reutilizados. El objetivo de la VV de la implementación es verificar y validar que estas transformaciones sean correctas, exactas, y completas. Incluye las siguientes tareas. i) Tarea: Análisis de seguimiento del código fuente. Forma FP.SI-1/0/5 (anexo II) ii) Tarea: Evaluación del código fuente y su documentación. iii) Tarea: Análisis del código fuente de las interfases.

11 Hoja: 11 iv) Tarea: Generación de los casos de prueba empleando la forma FP.SI-3/0/5 del anexo IV de: Componentes. Integración. Sistema. Aceptación. v) Tarea: Generación de procedimientos de prueba de: componentes. Integración. Sistema vi) Tarea: Ejecución de las pruebas de VV de los componentes. d) Verificación y Validación de Pruebas. (Sección 3.4). Las pruebas incluyen pruebas del software, pruebas de integración del software, las pruebas de integración de sistema. Las actividades de prueba de verificación y validación están relacionadas al ciclo de vida de desarrollo del software. El objetivo de la VV de la fase de pruebas es asegurarse de que los requerimientos del software y los requerimientos del sistema asignados al software son validados para la ejecución de las pruebas de integración, de sistema, y de aceptación. Incluye las siguientes tareas: i) Tarea: Análisis de seguimiento de las pruebas de VV. ii) Tarea: Generación del procedimiento de prueba de VV de aceptación. iii) Tarea: Ejecución y registro de la pruebas de integración en la forma de validación. Forma FP.SI-2/0/5 (anexo III). iv) Tarea: Ejecución de la pruebas de sistema v) Tarea: Ejecución de la prueba de aceptación e) Verificación y Validación de Instalación. (Sección 3.5). En la instalación y la comprobación, el producto de software es instalado y probado en el ambiente de trabajo. La actividad VV de la instalación y comprobación apoya las actividades de la instalación del software. El objetivo de VV de la instalación y la comprobación es verificar y validar correcta de instalación del software en el ambiente de trabajo. Incluye las siguientes tareas: i) Tarea: Inspección de la configuración de la instalación

12 Hoja: Reportes de VV ii) Tarea: Generación de Reporte final de VV, el cual se trata en el punto siguiente (Sección 4 del plan) En esta sección se debe describir cómo serán documentados los resultados de la implementación del PVV. Los reportes de VV se presentan durante todo el ciclo de vida del software. En esta sección se deben de describir los siguientes reportes. a) Reportes de Tareas (Sección 4.1) Estos son reportes de VV, sobre tareas individuales que se consideren relevantes y son puestos como reportes necesarios. Estos documentos deben indicar los resultados y el estado. b) Reportes de Anomalías (Sección 4.2) Las anomalías, pueden reportarse en la revisión técnica del software, en la forma FP.SI-4/0/5, anexo V, si la anomalía no impide el funcionamiento del software, de otra manera será como lo especifique el procedimiento de Plan de Administración de la Configuración. P.SI-4 [referencia 5.3]. c) Reporte final de VV (Sección 4.3) Al final de la VV se debe realizar un reporte resumido, indicado los resultados obtenidos de las tareas de VV en cada una de las fases de VV: Requerimientos, diseño, implementación, pruebas e instalación. El reporte final debe tener el siguiente contenido: 1 Introducción. 1.1 Objetivo 1.2 Alcances 1.3 Definiciones 1.4 Acrónimos 1.5 Referencias 1.6 Resumen 2. Desarrollo. 2.1 Resumen de las tareas de VV 2.1 Resumen de resultados 2.2 Resumen de anomalías y resoluciones 3. Valoración de la calidad del software 4. Recomendaciones 5. Anexos

13 Hoja: Procedimientos administrativos de la VV (Sección 5 del plan) En este punto se describen los procedimientos administrativos mínimos para el proceso de VV, y se presentan a continuación. a) Reporte y resolución de anomalías (Sección 5.1 del plan) El reporte y la resolución de las anomalías se realizan conforme a lo especificado en el P.SI-4 [referencia 5.3]. Además si es necesario se puede describir algún otro método de informar y resolverse las anomalías, incluso el criterio para informar una anomalía, la lista de distribución del informe de la anomalía y la autorización y límite de tiempo para resolverla. b) Políticas de iteración de tareas (Sección 5.2 del plan). Esta sección describe el criterio para determinar hasta que punto una tarea de VV es perfeccionada. Estos criterios pueden incluir valoraciones de cambio, programación, o efectos de calidad. c) Políticas de Desviación (Sección 5.3 del plan) Esta sección describe los procedimientos y formas cuando se encuentre una desviación en el Plan. La información requerida para las desviaciones incluirá identificación de la tarea, la razón de desviación, y efectos en la calidad del software. Esta sección define las autoridades responsables de aprobar las desviaciones. Una forma normal puede prepararse incluyendo la identificación de la tarea y la razón de la desviación. El personal capacitado y aprobando debe identificarse. Para los proyectos menores, menos formales, puede ser suficiente documentar la información requerida. d) Procedimientos de control (Sección 5.4) Esta sección identifica los procedimientos de control que serán aplicados al trabajo de VV. Estos procedimientos describen cómo los productos del software y resultados de software son configurados, protegidos y almacenados. Estos procedimientos pueden describir garantía de calidad, administración de la configuración, administración de datos, u otras actividades no especificada en otro lado. En esta sección se describe cómo el material del PVV deben cubrir las medidas de seguridad

14 Hoja: 14 4 RESPONSABILIDADES existentes y cómo la validación de resultados de VV deben ser protegidos de alteraciones deliberadas o accidentales. e) Estándares y Convenciones (Sección 5.5). Esta sección identifica los estándares y convenciones, que gobiernan la ejecución de tareas de VV. Éstas pueden incluir estándares y políticas de organización interna. Lo siguiente son ejemplos generales de normas y convenciones que pueden ser aplicables: i) Las normas para los requisitos del software, planeación, implementación, prueba, y documentación del software que será evaluado ii) Procedimientos detallados para las tareas de VV iii) Listas de chequeo detalladas para usarse en la evaluación del software iv) Estándares para revisiones e inspecciones. v) Los requisitos de garantía de calidad para el programa de VV. vi) Cualquier norma y convenciones requeridas por el contrato Dependiendo del ambiente del proyecto, a los estándares específicos y convenciones que puede requerirse cómo: i) Los Estándares de la Industria ii) Los Estándares profesionales iii) Las normas gubernamentales iv) Las normas reguladoras 4.1 Revisor Preparación del PVV conforme a este procedimiento Firmar de preparado el PVV generado en el SI. 4.2 Departamento de Sistemas Informáticos Realizar la revisión del PVV Firma de revisado el PVV generado en el SI. 4.3 Gerencia de sistemas Asegurar la correcta aplicación de este procedimiento Firmar de aprobado el PVV generado en el SI

15 Hoja: REFERENCIAS 5.1. Standard for Software Verification and Validation Plans, IEEE Std Programa de Aseguramiento de Calidad de Software de la GCN, PAG-14, Rev. 4, CFE, Diciembre del Plan de Administración de la Configuración de Software. P.SI-4, Rev. 1 ININ, Junio Plan de Garantía de Calidad de Software. PL.GC-12. Rev. Vigente ININ. 6. ANEXOS Anexo I Diagrama de flujo Anexo II Forma FP.SI-1/0/5 Matriz de Seguimiento Llenado de la matriz de seguimiento: (A) En este apartado se describe el nombre del proyecto/servicio (B) En ésta celda se pone el Número de registro de la Matriz de Seguimiento (C) Nombre del elemento al cual se le va realizar el Seguimiento (D) Nombre del elemento con el cual se va realizar el seguimiento (E) En éste apartado se sitúan los incisos o puntos específicos que se les va dar seguimiento (F) En éste apartado se ponen los incisos o puntos con los cuales se les da el seguimiento al punto anterior. (G) En este apartado se colocan los comentarios que se den al realizar el seguimiento (H) Nombre y firma del Revisor (I) Nombre y firma del Usuario (J) Fecha en que se realizó la Matriz de seguimiento. (K) Número de hoja parcial y total de la matriz de seguimiento

16 Hoja: 16 Anexo III Forma FP.SI-2/0/5 Registro de Validación Llenado de la forma de Validación (A) En este apartado se describe el nombre del proyecto/servicio (B) Nombre del Elemento que se va a verificar o validar (C) Número de hoja parcial y total de del registro de Verificación y Validación (D) En ésta celda se pone el Número de registro de Verificación y Validación (E) En éste apartado, se sitúan los criterios a considerar y se marca con una X la columna de cumple o no cumple según sea el caso. (F) En éste apartado, se marca Aceptado si la VV cumple con los criterios o No aceptado en el caso que no cumpla. En el caso que se solicite una Solicitud de cambio, se indica el número con el cual se genera la solicitud. (G) En el espacio de pie de página, se escribe el nombre y firma del revisor y del usuario, así como la fecha en que se realiza la VV. Anexo IV Forma FP.SI-3/1/5 Caso de Prueba Llenado de la forma de Caso de Prueba (A) En ésta celda se pone el número de registro del caso de prueba (B) Fecha en que se llevo a cabo el caso de prueba. (C) Número de hoja parcial y total de del registro de caso de prueba. (D) Nombre del Elemento al que corresponde el caso de prueba. (E) En éste apartado, se sitúan las instrucciones del caso de prueba. (F) En éste apartado se ponen las condiciones que se debe de contar para poder llevar el caso de prueba. (G) Aquí se describe los resultados que con base en el ERS y DDS se esperan al llevar a cabo el caso de prueba. (H) En éste apartado, se sitúan el procedimiento para llevar a cabo el caso de prueba. (I) En éste apartado, se describe el resultado que se obtuvo al llevar a cabo el caso de prueba. (J) Nombre y firma de la persona que participa como revisor. (K) Nombre y firma del revisor y del usuario

17 Hoja: 17 Anexo V Forma FP.SI-4/0/5 Revisión Técnica del Software Llenado de la forma Revisión Técnica del software (A) En este apartado, se describe el nombre del documento/proyecto (B) Nombre del Elemento al que corresponde el la revisión técnica. (C) En ésta celda se pone el número de revisión del documento si es que se trata de un documento, sino se queda en blanco. (D) En ésta celda la fecha de la revisión técnica. (E) En éste apartado, se sitúan las especificaciones de número de hoja, el apartado y el comentario, así como la resolución que se le de al comentario. (F) En el espacio de pie de página, se escribe el nombre y firma del revisor y del usuario

18 Hoja: 18 Anexo I Diagrama de flujo

19 Hoja: 19 Anexo II Forma FP.SI-1/0/5, Matriz de Seguimiento

20 Hoja: 20 Anexo III Forma FP.SI-2/0/5, Registro de Validación

21 Hoja: 21 Anexo IV Forma FP.SI-3/0/5, Caso de Prueba

22 Hoja: 22 Anexo V Forma FP.SI-4/0/5, Revisión Técnica del software.

23 Control ININ de Revisión y Aprobación de Documentos Título del documento: Verificación y Validación de Software Identificación: P.SI-5 \. \... Original A-r:. PREPARADO POR: M. en C. David Valdivia Rosas A~ ~CHA: Jun de 2007 REVISADO POR: M. en C. Alfonso Villarreal Martíne7~/hln. 1///./, ~CHA: Jun de 2007 APROBADO POR: M. en C. José Luis ÁnQeles Var6s/Y~ _lit:::: --/-.: FECHA: Jun de 2007 Revisión N ~.!/... ''''''''.1Jl PREPARADO POR: M. en C. David Valdlvla Rosas ~ A FECHA: Jun del 2010 REVISADO POR: M. en C. Alfonso Villarreal Martír.&',,/,,/// á~/. hi1' FECHA: Jun del 2010 APROBADO POR: M. en C. José Luis Ángeles4a16as.~v..t.. ~ FECHA: Jun del 2010 DESCRIPCiÓN DE LA REVISiÓN: Cambio a la forma FP.SI-3/Hp j._ GAIANTIA I ni. i Revisión N 2~ PREPARADO POR: M. en C. David Valdivia Rosas y'" /1 JlgOHA: lago del 2010 REVISADO POR: M. en C. Alfonso Villarreal Martínezf;'h/ü' /~.ú;fd.,fecha: Ago del 2010 APROBADO POR: M. en C. José Luis Ángeles V~; " l I..: 1/ FECHA: AQO del 2010 DESCRIPCiÓN DE LA REVISiÓN: Modificar el alcance del docurr,ento. Revisión N 3 I PREPARADO POR: REVISADO POR: APROBADO POR: DESCRIPCiÓN DE LA REVISiÓN: FECHA: FECHA: FECHA: Revisión N 4 ~ / PREPARADO POR: FECHA: REVISADO POR: FECHA: APROBADO POR: FECHA: DESCRIPCiÓN DE LA REVISiÓN: