Verificación de la Calidad en los Productos de Software Desarrollados

Transcripción

1 Página 1 de 7 1. Objetivo y Alcance Verificar que el aplicativo o módulo a ser entregado al área de Soporte Tecnológico cumpla con las exigencias del usuario y con los parámetros de calidad definidos por la Dirección de Interacción Social y Desarrollo Tecnológico. Comprende desde la recepción del aplicativo a probar hasta la notificación de la realización de pruebas. 2. Responsable El responsable de garantizar la adecuada ejecución del procedimiento Verificación de la calidad en los productos de software desarrollados por la Dirección de Interacción Social y Desarrollo Tecnológico de la Universidad de Pamplona, es el Coordinador Técnico de. 3. Definiciones 3.1 Centro de Asistencia Técnica (CAT) Es un aplicativo que permite el registro, seguimiento y control de las solicitudes técnicas, las cuales pasan por diferentes estados desde que se registran hasta que se cierran, permitiendo hacer trazabilidad al proceso realizado con cada una de ellas. 3.2 de Caja Negra Consisten en verificar que los requerimientos cumplan con los requisitos funcionales establecidos por el cliente y consignados en los entregables realizados en el diseño e implementación del sistema. 3.3 Requerimientos Definición clara y precisa de los aspectos más relevantes del producto contratado, está orientado a satisfacer las necesidades de manera eficaz, eficiente y transparente. 3.5 Servidor de POST-DESARROLLO Servidor que sirve de repositorio para almacenar las versiones preliminares que se liberan en el proceso de desarrollo y que deben formar parte de un proceso de pruebas. 3.6 Servidor de DESPLIEGUE Servidor que sirve de repositorio para almacenar las versiones liberadas al cliente después del proceso de pruebas. Elaboró Aprobó Validó Firma Ing. Yolanda Pérez Cárdenas Firma Ing. Elvis Navarro Vega Firma Mg. Maria Victoria Bautista Bochagá Fecha 28 de noviembre de 2011 Fecha 30 de noviembre de 2011 Fecha 15 de diciembre de 2011

2 Página 2 de Parche Corresponde a una actualización o ajuste realizado sobre un producto de software antes de la liberación de una próxima versión. Las demás definiciones que aplican para el presente documento se encuentran contempladas en la Norma NTC ISO 9000:2005 Sistema de Gestión de la Calidad. Fundamentos y Vocabulario. 4. Contenido Responsable: Coordinador Técnico de 4.1 Recepción del Aplicativo a Probar Envía una solicitud a través del Centro de Asistencia Técnica (CAT) informando que se ha liberado una nueva versión y referenciando una relación de requerimientos que deben ser revisados. Ver procedimiento PSE-18 Liberación de Versiones de Desarrollo, inciso 4.3. Cada uno de los requerimientos del CAT que debe ser revisado es asignado por el Coordinador Técnico de a un para que ejecute la revisión. 4.2 Descripciones Generales del Software Responsable: Desarrollado Revisa la información asociada al aplicativo o requerimiento a probar para conocer lo pertinente acerca de la revisión a realizar. Esta información estará incluida en la descripción del mismo requerimiento del CAT y la solución realizada podrá ser consultada en la casilla de observación. Si considera necesario complementar información, el solicita al Consultoría, al Coordinador Técnico de Desarrollo del producto y/o al(los) Analista(s) de Desarrollo que participó(aron) en el diseño y desarrollo de la versión o parche liberado una socialización o explicación de todo o parte del conjunto de soluciones a verificar. 4.3 Identificación de Condiciones y Requisitos para Aplicar las del Software Desarrollado Responsable: Antes de iniciar con la aplicación de las pruebas al software desarrollado, debe cumplir con: 1. Comprensión del problema que se está resolviendo. 2. Para reducir los supuestos y los términos ambiguos frente a procesos reales a revisar, se recomienda realizar un glosario (opcional). 3. Identificar a través de la documentación y levantamiento de información realizado por el Consultoría o Soporte los procesos que debe cubrir el software.

3 Página 3 de 7 4. Conocer los límites y restricciones del sistema para entender la estrategia del producto a corto y largo plazo y poder efectuar las pruebas respectivas. 5. Identificar datos válidos y datos inválidos para las pruebas. 6. Verificar lo establecido entre el Consultoría y el Desarrollo al finalizar la implementación del requerimiento. 7. Identificar las condiciones de prueba funcionales, el comportamiento del sistema, los cursos de acción normal y alternativas que dan origen a las condiciones de prueba dentro de la especificación de requerimientos. Se utilizan los casos de uso (opcionales) para definir las estrategias de las pruebas o éstas se construyen a partir de la descripción detallada de los procesos registrados en el levantamiento de información (o documentos anexos al levantamiento como los reglamentos, estatutos, acuerdos, decretos). 8. Identificar los requerimientos No funcionales que afectan directamente el funcionamiento del sistema. Dentro de estas pruebas se identifican las siguientes: de rendimiento, pruebas de seguridad y pruebas de disponibilidad. 9. Realizar las pruebas teniendo en cuenta una miscelánea de casos posibles que el usuario puede aplicar como datos de entrada al aplicativo. 10. Validar que el software cumpla a cabalidad las solicitudes realizadas por el cliente. 4.4 de Caja Negra del Aplicativo Responsable: 1. Recibido el requerimiento a través del Centro de asistencia Técnica (CAT), para la prueba de una liberación, ajuste o parche, se distribuye el trabajo para iniciar con el proceso de actualización del sitio de. 2. El Producto al cual se le va a realizar la prueba debe estar identificado con un número de versión de acuerdo a lo definido en la GSE-26 Asignación de Números de Versiones a los Productos de Software. 3. Se accede al Servidor de POST-DESARROLLO, a la subcarpeta de la versión del producto para tomar los empaquetados (TAR.GZ) de la liberación, teniendo en cuenta la estructura de carpetas definidas para ese servidor (ver procedimiento PSE-18 Liberación de Versiones de Desarrollo, inciso 4.1) y se actualiza el servidor de pruebas. 4. El registra la prueba de caja negra (ver ISE-38 Creación de de Caja Negra) en el Centro de Asistencia Técnica (CAT) y da comienzo al proceso de pruebas del módulo o aplicativo (ver TSE-01 Realización de ), una vez realizada la configuración necesaria en el servidor de pruebas destinado para ello, determinando los criterios de aceptación del mismo. Los resultados tanto de éxito como de errores se registran en el Centro de Asistencia Técnica (CAT), mediante el FSE-16

4 Página 4 de 7 de Caja Negra. Si durante el proceso de la Prueba, el encuentra errores u otros problemas que le impidan desarrollar una prueba exitosa reporta estos inconvenientes realizando una petición de correcciones a través del Centro de Asistencia Técnica (CAT) debe estar asociado a una prueba de caja negra (ver ISE-38 Creación de de Caja Negra), enviando el requerimiento de corrección (en estado REGISTRADO) al Coordinador Técnico de Desarrollo del Proyecto, quien a su vez le asigna este requerimiento al funcionario encargado. Ver el procedimiento PSE-15 Atención de Solicitudes Técnicas. O si por el contrario el va a emitir una solicitud de mejora al aplicativo que está probando, deberá realizar el proceso descrito anteriormente. Una vez se realizan las correcciones el Desarrollo encargado cambia el estado del requerimiento (a estado PRUEBAS) colocando una observación que describa completamente la solución aplicada, con lo cual se indica que esta petición ya fue solucionada. Posteriormente, el Desarrollo informa a través de las herramientas de comunicación establecidas al para que éste realice las pruebas necesarias y verifique el cumplimiento de lo requerido. 5. Las consideraciones nuevas recibidas en el archivo Consideraciones de Instalacion.txt o en un leame.txt deben ser incluidas en el documento guía de instalación nombre_del_proyecto.pdf (Este documento es opcional). 6. Terminadas las pruebas, el elabora el formato FSE-50 Nota de Lanzamiento, basado en el ISE-37 Elaboración de la Nota de Lanzamiento y se relacionan por cada proyecto los requerimientos que son solucionados en la liberación que se está documentando. Para este proceso, el se debe apoyar en la documentación recibida a través de cada requerimiento del CAT. 7. Si el desarrollo de las pruebas contienen procesos complejos, éstos son registrados en el FSE-49 Descriptor de Procesos (opcional), para su diligenciamiento el debe basarse en el ISE-36 Elaboración del Descriptor de Procesos. 8. Para finalizar el proceso de pruebas, el registra los éxitos tenidos en la prueba de caja negra exitosa ver ISE-38 Creación de de Caja Negra. 4.5 Empaquetamiento del Producto para el Responsable: Coordinador Técnico de Despliegue Finalizado el proceso de pruebas se da inicio al despliegue del producto realizando los siguientes pasos. Si el Coordinador Técnico de lo considera apropiado puede delegar esta actividad en un : 1. Se prepara el ambiente necesario para generar el empaquetado de la versión o el

5 Página 5 de 7 parche que se liberará al Cliente. Para la generación del empaquetado se toman los archivos contenidos en el Publicador de teniendo en cuenta no incluir documentos temporales (archivos de imágenes en cualquier extensión, archivos con extensiones pdf, doc, xls, txt, entre otros archivos temporales que se generen como resultado de los procesos de pruebas). 2. Se procede a generar los empaquetados de la versión o el parche, almacenándolos en el Servidor de DESPLIEGUE, en una subcarpeta con el número de versión o parche liberado dentro de la carpeta correspondiente al producto. La información dentro de la subcarpeta del número de versión o parche obedece a la siguiente estructura: BD Versión (Scripts de la Base de Datos completa) Actualización (Scripts de actualización de esta versión) Docs (Documentación de la versión) Web Versión (TAR.GZ del sitio completo) Actualización (TAR.GZ de la actualización de esta versión) Docs (Documentación de la versión) Se deben generar empaquetados independientes para Clientes que deban montar la versión completa y para clientes que sólo requieran actualización. La versión completa se guarda en las subcarpetas: BD/Version (export o scripts de base de datos) y Web/Version (contexto de la aplicación) y la Actualización se guarda en las subcarpetas BD/Actualizacion (scripts de base de datos) y Web/Actualizacion (contexto de la aplicación). Cuando la versión corresponda a un Parche (ejemplo: ) no se incluyen las subcarpetas Version (BD/Version y Web/Version), puesto que solamente se incluye la actualización. En este caso, los Scripts de Base de Datos, la documentación y el TAR.GZ deben incluir solamente los ajustes correspondientes a ese parche. Los documentos elaborados o actualizados en y que deban ser colocados en el servidor de DESPLIEGUE (ejemplo Consideraciones de Instalación, Notas de Lanzamiento, Descriptor de Procesos), se copian en la subcarpeta Web/Docs. 3. Se actualiza el documento Versiones de Aplicativos.xls ubicado en la carpeta principal del servidor de DESPLIEGUE, para incluir allí el número de la versión liberada, la fecha de liberación en pruebas, el nombre del Proyecto y el nombre del Producto. 4.6 Actualización Aislada de Scripts de Responsable: Coordinador Técnico de Base de Datos Cuando se requiera generar una actualización de un producto, la cual no incluya cambios en las páginas o clases de la aplicación, sino solamente modificaciones en los objetos de la base de datos, se debe construir en el servidor de DESPLIEGUE una estructura similar a la indicada en el inciso anterior.

6 Página 6 de 7 El Coordinador Técnico de Desarrollo determinará si esta actualización corresponde a una nueva versión del producto o a un nuevo parche. En cualquiera de los casos el Coordinador Técnico de creará en el Servidor de DESPLIEGUE una subcarpeta con el número de la versión o parche liberado dentro de la carpeta correspondiente al producto. La estructura dentro de la subcarpeta del número de versión o parche debe contener solamente lo correspondiente a base de datos, así: BD Version (Scripts de la Base de Datos completa) Actualizacion (Scripts de actualización de esta versión) Docs (Documentación de la versión) Finalmente, el Coordinador Técnico de solicita mediante las herramientas de comunicación al Base de Datos el copiado de la información respectiva (Scripts y documentación) en las carpetas establecidas para ello. 4.7 Notificación de Despliegue de una Responsable: Coordinador Técnico de Nueva Versión Una vez generado el empaquetado de la nueva versión o parche en el Servidor de DESPLIEGUE se le informa mediante correo electrónico al Área Soporte Tecnológico y al Área Desarrollo Tecnológico sobre la versión que se acaba de liberar, indicando el nombre del proyecto, nombre del producto y número de versión; de igual manera se le informa al Coordinador Técnico de Desarrollo del Proyecto mediante las herramientas de comunicación establecidas, que la versión ha sido liberada y se encuentra en el servidor de DESPLIEGUE. Esta actividad puede ser delegada por el Coordinador Técnico de a un Analista de. 5. Documentos de Referencia - NTC ISO 9000:2000 Sistema de Gestión de la Calidad. Fundamentos y Vocabulario. - NTC ISO 9000:2005 Sistema de Gestión de la Calidad. Fundamentos y Vocabulario. - NTC ISO 9001:2000 Sistema de Gestión de la Calidad. Requisitos. - NTC ISO 9001:2008 Sistema de Gestión de la Calidad. Requisitos. - NTC GP 1000:2004 Norma Técnica de Calidad en la Gestión Pública. - NTC GP 1000:2009 Norma Técnica de Calidad en la Gestión Pública. - Modelo Estándar de Control Interno - PAC-01 Elaboración y Control de Documentos del SIG. - PSE-15 Atención de Solicitudes Técnicas - PSE-18 Liberación de Versiones en Desarrollo - ISE-36 Elaboración del Descriptor de Procesos - ISE-37 Elaboración de la Nota de Lanzamiento - ISE-38 Creación de de Caja Negra - GSE-26 Asignación de Números de Versiones a los Productos de Software.

7 Página 7 de 7 - Consideraciones de Instalacion.doc - TSE-01 Realización de 6. Historia de Modificaciones Versión Naturaleza del Cambio Variación de rol y Modificación de Actividades Actualización del documento Por directrices de la Administración del Sistema de Gestión de la Calidad Fecha de Aprobación Fecha de Validación 09/11/ /11/ /09/ /11/ /10/ /10/ Actualización del documento 30/11/ /12/ Actualización del documento 30/05/ /06/ Actualización del documento 26/08/ /08/ Actualización del documento. 29/05/ /06/ Ver acta No /02/ /03/ Actualización del documento 09/07/ /07/ Actualización de la documentación según lo descrito en el acta del 30 de noviembre de /11/ /12/ Administración de Formatos Código Nombre Responsable Ubicación Acceso FSE-16 FSE-49 FSE Anexos No Aplica de Caja Negra Descriptor de Procesos Notas de Lanzamiento Aplicativo CAT Servidor de despliegue Servidor de despliegue Tiempo de retención Según las TRD Según las TRD Según las TRD Disposición Archivo Central de la Universidad Archivo Central de la Universidad Archivo Central de la Universidad