ESPECIFICACIONES Guía de Calidad del Software ES-GPRO

Transcripción

1 ESPECIFICACIONES Guía de Calidad del Software ES-GPRO

2 Participantes en el ciclo de aprobación de esta versión del documento: Elaboradores Consultores Revisores Aprobadores Alejandro Jiménez López Maria Eugenia Díez Crespo Luisa Muñoz Carmona Begoña Delgado Rico José Antonio Peláez Pamos (UOR de Organización) Antonio Fernández Moreno Margarita Gil Trinidad (UOR de Organización) Julia Molina Franquelo Histórico del documento: Nº de Fecha puesta Razones de los cambios respecto a la versión anterior Versión en vigor 1.0 Creación (31/10/2013) En el servicio de revisión de código, adaptación para mantener coherencia con las fases y entregables indicados en la Guía de Gestión de Proyectos que está en --- elaboración. (2/12/2013) 1.2 Detalle del alcance y proceso de creación de escenarios (16/1/2014) Adaptación para publicación en el Sistema de Gestión Documental de Calidad de ICM (SGDC), según normativa vigente. 10/2/ Compatibilidad con Subversion. Gestión de requisitos técnicos. Registro en Mantis. (14/7/2014) 8/9/ Entrega de resultados en pruebas de rendimiento. Posibilidad de suficiencia con las pruebas del proveedor. (5/9/2014) Revisiones de Código: se revisa el alcance según tecnología y se mejora el seguimiento del cumplimiento de las reglas críticas. Pruebas de rendimiento: se mejora el procedimiento para que el código probado sea el código instalado en Producción. Alineamiento de este documento con la Guía de Gestión de Proyectos de Desarrollo de SSII (30/3/2015) 25/5/2015 Cualquier copia en papel o archivada fuera del SGDC no tiene validez como original, debiendo contrastar en este sistema la versión En Vigor para poder ser utilizada. Página 2 de 21

3 ÍNDICE 1. INTRODUCCIÓN OBJETO DEL DOCUMENTO ÁMBITO DE APLICACIÓN TÉRMINOS Y DEFINICIONES Acrónimos Definiciones DISPOSICIONES LEGALES Y NORMATIVA SERVICIOS DE CALIDAD DEL SOFTWARE Revisión de código estático Definición Utilidad Modelo de prestación Entregables Tareas propias de la UOR de Calidad del SW y tiempos de servicio Pruebas de rendimiento Definición Utilidad Modelo de prestación Entregables Tareas propias de la UOR de Calidad del SW y tiempos de servicio ANEXOS Relación de intervinientes en las actividades mencionadas Puntos de información y contacto Portal para la provisión de los servicios de Calidad Servicio idóneo según Necesidad Servicios disponibles DOCUMENTOS RELACIONADOS Página 3 de 21

4 1. INTRODUCCIÓN La función de calidad, en el ámbito de calidad de un sistema de información, vela por que el sistema cumpla los requerimientos especificados y las necesidades o expectativas del usuario. Se mide por tres aspectos fundamentales: Operativa: Correcto funcionamiento. Fiabilidad. Eficiencia. Seguridad. Facilidad de uso. Capacidad de cambio: Facilidad de mantenimiento. Flexibilidad para soportar cambios (Escalabilidad). Facilidad de prueba. Adaptabilidad a otros entornos: Portabilidad a otros entornos (Portabilidad). Reutilización de la solución. Interacción con otros sistemas (Compatibilidad). La calidad por tanto, pretende verificar que el sistema de información hace lo que tiene que hacer y lo hace como lo tiene que hacer. En el caso de ICM, el qué responde a los requisitos y necesidades funcionales de sus clientes de la Comunidad de Madrid, y el cómo responde a la normativa y buenas prácticas de gestión de proyectos, a las metodologías de desarrollo y a las arquitecturas de componentes que ICM establece. En ICM, esta función de calidad de un sistema de información, la define y ejecuta la unidad organizativa responsable de Calidad y Certificación del software (en adelante UOR de Calidad del SW), y se centra principalmente en la calidad del software desarrollado, es decir, se verifica si el código cumple la normativa de desarrollo, y se realizan pruebas de rendimiento para determinar si el sistema se puede utilizar de forma eficiente por el usuario. Estas actividades dan lugar a dos servicios técnicos que se denominan revisión de código estático y pruebas de rendimiento. En esta guía de calidad del software se describen estos servicios, indicando entre otras cosas, su utilidad y su modelo de prestación de servicio. Además se presentan unos cuadros resúmenes de estos servicios de calidad del software que pretenden facilitar al responsable de proyecto o del mantenimiento evolutivo/correctivo, qué servicio tiene que solicitar en función de sus necesidades y/o de la tecnología en que esté desarrollado el software. Página 4 de 21

5 2. OBJETO DEL DOCUMENTO Los objetivos de esta guía de calidad del software son los siguientes: Definir los servicios técnicos de calidad del software, indicando su utilidad, su modelo de prestación, sus entregables y su ANS. Determinar claramente el ámbito de actuación de la función de calidad del software en ICM. Complementar la guía de proyectos de desarrollo de aplicaciones de ICM en el ámbito de calidad del software, especificando con más detalle las características de los servicios. Establecer las responsabilidades y actividades que todos los intervinientes deben cumplir para garantizar la prestación del servicio de forma eficaz y eficiente. 3. ÁMBITO DE APLICACIÓN Esta guía aplica a los desarrollos de software correspondientes a nuevos sistemas de información y al mantenimiento evolutivo o migración de los existentes. Están excluidos los correspondientes a mantenimientos correctivos. 4. TÉRMINOS Y DEFINICIONES 4.1 Acrónimos ICM GGPD RP SAVT SW UO UOR de Agencia de Informática y Comunicaciones de la Comunidad de Madrid Guía de gestión de proyectos de desarrollo de sistemas de información (ver apartado Documentos relacionados ) Responsable de Proyecto: persona de ICM que desempeña el rol de responsable del proyecto de desarrollo de un nuevo sistema de información, mantenimiento evolutivo de uno ya existente o migración, y de la entrega del servicio solicitado. Servicio Automático de Verificación Telemática: aplicación para la Revisión de Código en modalidad autoservicio y automático. Software Unidad Organizativa (genérica) Unidad Organizativa Responsable de una función Página 5 de 21

6 4.2 Definiciones Certificación - Concepto extendido en ICM para denominar a la revisión de código estático. Se trata del proceso de confrontar el código fuente frente a las buenas prácticas adoptadas en el mercado y la normativa de ICM. Mantenimiento evolutivo Incluye los de tipo Adaptativo, Perfectivo, y Preventivo. Siendo el Adaptativo la agrupación de actividades motivadas por cambio técnico o funcional. El Perfectivo es cualquier cambio a un sistema después de una entrega previa y con el objetivo de mejorar el funcionamiento o mantenibilidad. Por último el Preventivo son las actividades realizadas con el propósito de prevenir problemas latentes antes de que estos ocurran, sin modificación de funcionalidad. Huella - Una huella digital es un conjunto de datos asociados a un mensaje que permiten asegurar que el mensaje no fue modificado. La huella digital o resumen de un mensaje se obtiene aplicando una función, denominada hash, a ese mensaje, esto da como resultado un conjunto de datos singular de longitud fija. Una función hash tiene entre otras las siguientes propiedades: Dos mensajes iguales producen huellas digitales iguales. Dos mensajes parecidos producen huellas digitales completamente diferentes. Dos huellas digitales idénticas pueden ser el resultado de dos mensajes iguales o de dos mensajes completamente diferentes. Una función hash es irreversible, no se puede deshacer, por tanto su comprobación se realizará aplicando de nuevo la misma función hash al mensaje. Proveedor A lo largo del documento se usa este término en distintas acepciones: Empresa a la que se adjudica la construcción de un nuevo desarrollo o mantenimiento evolutivo. Equipo de personas que realiza el trabajo asignado. Tiene un responsable, quién también hace la función de interlocutor único. Técnico de la empresa en cuestión que participa en cualquiera de las funciones contratadas al efecto: análisis, codificación, pruebas, etc. UOR de Calidad del SW - Unidad Organizativa competente en materia de Calidad del software. Responsable de la prestación de los servicios de Calidad del software. UOR de Arquitectura SW - La UO de ICM responsable de la normativa de obligado cumplimiento por tecnología y/o lenguaje de programación. También la competente en autorizar o no las peticiones de incumplimiento de dicha normativa atendiendo a la justificación argumentada en la solicitud correspondiente. UOR de Servicios al Cliente UO responsable de la gestión del cliente para quien se hace el nuevo desarrollo, mantenimiento evolutivo o migración. Página 6 de 21

7 5. DISPOSICIONES LEGALES Y NORMATIVA ISO 9126: Estándar internacional para la evaluación de la calidad del software. 6. SERVICIOS DE CALIDAD DEL SOFTWARE 6.1 Revisión de código estático Definición Comparación del código fuente frente a las buenas prácticas y normativa de ICM. Las buenas prácticas y normativa conforman un referente que adopta ICM porque estima que garantizan un mínimo de calidad en las características que destaca el estándar ISO 9126 "Software engineering - Product quality". En el proceso no se ejecuta el código. En ICM a este servicio se le denomina también Certificación de código Utilidad Es la de conocer el grado de cumplimiento de las buenas prácticas y de la normativa de ICM que define la UOR de Arquitectura SW. Entre las ventajas de un mayor cumplimiento destacan: La estandarización del código y su utilidad de cara a tareas de mantenimiento y configuración de la aplicación. Un menor esfuerzo y coste para la integración con terceras aplicaciones ya presentes en ICM. La facilidad de inclusión en procesos más automatizados de certificación, pruebas, y despliegue en entornos de ICM Modelo de prestación Alcance y ámbito tecnológico Todo código construido para ICM que resulte en un módulo técnico de una aplicación un webservice un batch Con motivo de: Nuevos desarrollos de sistemas de información según la GGPD Migración de Tecnología en Módulos de Aplicaciones. Página 7 de 21

8 Y que el código sea de alguna de las siguientes tecnologías: JAVA Framework ATLAS. JAVA Framework2. JAVA Framework Justicia. Modelo de datos en Erwin v4 y v7. Portales desarrollados con Joomla. NOTA: Ver la tabla detallada en el ANEXO de servicios disponibles Características La UOR de Calidad del SW pone a disposición de los usuarios el soporte al servicio de Revisión de Código Estático a través del Portal para el Desarrollo de Aplicaciones, ( eligiendo el proyecto CALIDAD. En ICM el código fuente está agrupado en módulos técnicos. La unidad mínima de código sobre la que se presta el servicio de revisión de código es el módulo técnico. El proveedor tiene la OBLIGACIÓN de cumplir la normativa de ICM en el código que desarrolle y/o modifique. Para asegurar el cumplimiento debe actuar según la presente guía y la GGPD. Se trata de un PROCESO ITERATIVO hasta que la revisión de código sea SATISFACTORIA. En ese proceso debe utilizar el servicio SAVT de ICM que proporciona información acerca del grado de cumplimiento de la normativa de ICM de una manera ágil y en modo autoservicio. La normativa de ICM debe cumplirse con independencia de las prestaciones del servicio SAVT. El SAVT está a disposición del proveedor dependiendo de la tecnología. Es accesible de forma remota y se puede utilizar el número de veces que sea necesario. Actualmente SAVT está disponible para las siguientes tecnologías: JAVA Framework ATLAS. JAVA Framework2. JAVA Framework Justicia. Modelos de datos en Erwin v4 y v7. En estos casos, ICM exige que el proceso de revisión de código se realice con una periodicidad máxima semanal. El RP es responsable de la obtención de la revisión de código satisfactoria. EXCEPCIONALMENTE y siempre con la debida autorización (el procedimiento a seguir está descrito en la GGPD), se podrá solicitar el paso a producción sin la ejecución de la revisión del código. En este caso, el RP deberá a posteriori solicitar la revisión del código siguiendo el procedimiento previsto en la GGPD. Página 8 de 21

9 El procedimiento, alcance y herramientas de la UOR de Calidad del SW para validar el cumplimiento de la normativa pueden evolucionar según tecnología y proyecto, aunque siempre dentro de los límites que marca la versión de la normativa. La UOR de Calidad del SW revisa y completa el informe de revisión de código generado automáticamente en SAVT, pudiendo cambiar el resultado del informe Fases y actividades La revisión de código es un medio para conseguir mejorar el código fuente y no un fin. Por tanto, debe planificarse como una tarea continua durante todas las fases del proyecto, ya sea para crear o modificar las aplicaciones. En el caso de que el proveedor detecte en el desarrollo excepciones a la Normativa de ICM, realizará la gestión según la GGPD. Resumidamente consiste en solicitar la autorización del incumplimiento de normativa explicando las razones. Esta solicitud se enviará a la UOR de Arquitectura SW que se pronunciará sobre si autoriza o no el incumplimiento de la normativa. En caso de autorización, la solicitud de revisión de código a la UOR de Calidad del SW se acompañará siempre con los documentos acreditativos expedidos por la UOR de Arquitectura SW. El RP debe solicitar a la UOR de Calidad del SW un escenario particular en SAVT para su proyecto, que contemple las excepciones al cumplimiento de la parte de normativa autorizadas por la UOR de Arquitectura SW. La UOR de Calidad del SW creará en SAVT un escenario ad hoc para el proyecto, con el objetivo de que el servicio no valore negativamente en las siguientes revisiones de código los incumplimientos ya autorizados. La solicitud de creación del escenario particular la debe realizar el RP a la UOR de Calidad del SW mediante consulta en el Portal para el Desarrollo, seleccionando proyecto CALIDAD y categoría ESCENARIO PARTICULAR. En la solicitud hay que adjuntar las autorizaciones proporcionadas por la UOR de Arquitectura SW. Proceso dependiendo de la tecnología empleada en el módulo técnico: A- Si está soportada por SAVT: 1. El proveedor tiene la obligación de revisar el código con este Servicio, desde sus instalaciones. El proveedor debe solicitar su usuario al delegado de su empresa para la gestión de SAVT. Si no existiera todavía el usuario delegado y/o la empresa, el RP solicitará a la UOR de Calidad del SW las credenciales de un nuevo usuario de perfil Responsable de Empresa para la gestión de SAVT, así como la creación de la propia empresa si no existiera. La petición será a través de consulta sobre CALIDAD según indicado anteriormente, mediante una solicitud de tipo Gestión de Usuarios en SAVT, indicando: el nombre de la empresa nombre completo del usuario correo electrónico de empresa de la persona delegada por el proveedor. NOTA: Obligatoriamente la petición debe estar monitorizada por el jefe del área responsable del proyecto. Para ello, después de crear la petición, basta volver a editarla indicando el login del jefe Página 9 de 21

10 de área en el campo monitorización de la petición. En las comunicaciones a propósito de la gestión de la petición, el sistema mandará copia a los destinatarios añadidos mediante este mecanismo. 2. El proveedor ejecuta frecuentemente la revisión y subsana los incumplimientos. 3. En los hitos de entrega el proveedor remitirá al RP el Informe de Revisión de Código que emite SAVT una vez no contenga incumplimientos de normativa, como evidencia de la realización de las citadas revisiones. Aun así, el RP chequeará estos informes y verificará si aparecen incumplimientos de normativa. En caso de duda, el RP se pondrá en contacto con la UOR de Calidad del SW. El proceso se repite hasta que el informe evidencie que SI se cumple la normativa. El RP puede consultar los informes de revisión en SAVT previa solicitud de autorización de acceso a la UOR de Calidad del SW. 4. Cuando el RP gestione la entrega oficial del módulo técnico según la GGPD, solicitará la revisión de su código estático a la UOR de Calidad del SW mediante solicitud a través del Portal para el Desarrollo de Aplicaciones, ( eligiendo el proyecto CALIDAD y la categoría SOLICITUDES REVISIONES CÓDIGO adjuntando: a. el formulario según plantilla de ficha de entrega disponible en b. la confirmación de que las pruebas funcionales son satisfactorias. c. dirección del repositorio donde está el código fuente a revisar. i. Si se ha empleado Subversion la dirección debe ser la etiqueta de entrega acorde a la guía de uso de Subversion para desarrollos paralelos; documento de la UOR de Arquitectura. ii. Si NO se ha empleado Subversion, la dirección debe identificar la localización del código fuente en formato ZIP, así como la huella digital que proporciona SAVT y que identifica unívocamente el código revisado. El nombre del ZIP debe coincidir con el nombre del módulo técnico. 5. La UOR de Calidad del SW, una vez finalizado el proceso de revisión de código, genera el informe de revisión de código firmado con el identificador de Calidad. i. Si se ha empleado Subversion, la UOR de Calidad del SW copia el informe de revisión de código en la carpeta certificados de la etiqueta de entrega de Subversion. ii. Si NO se ha empleado Subversion, la UOR de Calidad del SW copia el informe de revisión de código en la misma localización del ZIP proporcionado. Página 10 de 21

11 NOTA: Observar que el módulo técnico que se desplegará en Producción será, según el caso, el correspondiente a los ficheros contenidos en la etiqueta entrega de Subversion o del fichero ZIP analizados previamente por SAVT con resultado satisfactorio. B- Si NO está soportada por SAVT: 1. El RP comparte con la UOR de Calidad del SW la planificación del proyecto y pone en su conocimiento el Plan de Entregas, de tal forma que la UOR de Calidad del SW conoce con antelación en qué casos y cuando se le va a solicitar una revisión de código, tanto para las entregas parciales, como para la entrega final. Es decir, en este caso el proceso de revisión de código está alineado con el Plan de Entregas del proyecto. 2. El RP gestiona la entrega del proveedor y su instalación en ICM según la GGPD. Tras la instalación y pruebas funcionales satisfactorias el RP solicitará a la UOR de Calidad del SW mediante solicitud a través del Portal para el Desarrollo de Aplicaciones, ( eligiendo el proyecto CALIDAD y la opción SOLICITUDES REVISIONES CÓDIGO adjuntando: el formulario según plantilla de la ficha de entrega disponible en la confirmación de que las pruebas funcionales son satisfactorias. dirección en el repositorio de entregas de proveedor donde está el código fuente a revisar. 3. La UOR de Calidad del SW, una vez finalizado el proceso genera el informe de revisión de código: a. Si se ha empleado Subversion, la UOR de Calidad del SW copia el informe de revisión de código en la carpeta certificados de la etiqueta de entrega de Subversion. b. Si NO se ha empleado Subversion, la UOR de Calidad del SW copia el informe de revisión de código en la misma localización del ZIP proporcionado. Si el informe NO es satisfactorio el RP se responsabiliza de que se apliquen las acciones correctoras necesarias. Luego comienza nuevamente otro ciclo de revisión, y así sucesivamente hasta que el informe sea satisfactorio Participantes La UOR de Calidad del SW tiene la competencia de revisar el cumplimiento de la normativa verificando un subconjunto variable de controles aunque siempre dentro del ámbito de la normativa. El proceso, según la tecnología, puede ser automático o manual. Página 11 de 21

12 La UOR de Arquitectura SW tiene la competencia de definir la normativa de obligado cumplimiento por tecnología y/o lenguaje de programación. El RP de nuevo desarrollo o del evolutivo. El proveedor del nuevo desarrollo o evolutivo de un módulo técnico de la aplicación Entregables El RP verifica que las revisiones de código se están haciendo y se asegura de recibir y almacenar los Informes de Revisión de Código que le entreguen el proveedor o la UOR de Calidad del SW. El RP se debe asegurar que el Informe de Revisión de Código correspondiente a la Entrega Final es favorable. Los entregables varían atendiendo a la tecnología del código del módulo técnico y a la herramienta empleada. A. Si está soportada por SAVT: El resultado lo conforman el informe de revisión generado por SAVT más el detalle de cada incumplimiento, por línea de código, fichero y módulo técnico, disponible dentro de la herramienta empleada en SAVT. El resultado lo obtiene el usuario de forma autónoma seleccionando en el desplegable Fase el valor Entrega en la pantalla de Verificación de Código. Las instrucciones están disponibles en el manual disponible en el menú Documentación de la propia herramienta. El informe de revisión está encabezado por una gráfica comparativa del cumplimiento de la normativa de ICM según las categorías presentes de la ISO9126. El informe de revisión de código de un módulo técnico es favorable cuando la gráfica de la curva del cumplimiento de la ISO9126 correspondiente al código del módulo técnico evaluado es superior o igual a la curva de mínimos que exige ICM y además los posibles incumplimientos residuales no alcanzan a las reglas consideradas críticas. En respuesta a la solicitud del RP de revisión de código a una entrega oficial del módulo técnico, la UOR de Calidad del SW realizará las tareas indicadas en el apartado al efecto e informará al RP solicitante. B. Si NO está soportada por SAVT: El resultado es un informe que presenta y detalla los identificadores de la normativa incumplida, si procede. El informe de revisión de código de un módulo técnico es favorable cuando no aparecen incumplimientos a la normativa Tareas propias de la UOR de Calidad del SW y tiempos de servicio Una vez recibida la solicitud a través del Portal para el Desarrollo de Aplicaciones, ( eligiendo el proyecto CALIDAD y la categoría SOLICITUDES REVISIONES CÓDIGO y validada su completitud, la UOR de Calidad del SW informa al Página 12 de 21

13 peticionario del registro correcto de la solicitud y la cierra. Queda en cola la solicitud mientras se atienden otras anteriores. Cuando le toca el turno, la UOR de Calidad del SW informa de la fecha estimada de finalización y una vez realizada la revisión envía el resultado al RP solicitante. El tiempo necesario estimado varía atendiendo a la tecnología del código del módulo técnico y a la herramienta empleada: A. Si está soportada por SAVT: Acorde con la GGPD y la presente guía se espera que la solicitud sea sobre algún módulo ya autocertificado por el proveedor. En esa situación la UOR de Calidad del SW emplea un tiempo mínimo para la comprobación de la calificación y el análisis de riesgo de posibles incumplimientos residuales. La estimación es de 1 día laborable por cada módulo técnico, lo cual es el objetivo de cumplimiento para el 85% de las solicitudes B. Si NO está soportada por SAVT: Dentro del turno de un módulo técnico, la estimación es de 2 días laborables; lo cual es el objetivo de cumplimiento para el 85% de las solicitudes. 6.2 Pruebas de rendimiento Definición Pruebas que tienen por objetivo determinar la escalabilidad del código desarrollado, así como su fiabilidad y uso de recursos técnicos. El objetivo principal de las pruebas es el de confirmar un rendimiento que supere los mínimos recogidos en el documento de requisitos. Las pruebas contribuyen de forma destacada a asegurar que ICM presta un servicio de calidad a través de sus aplicaciones. Las pruebas de rendimiento que ejecuta la UOR de Calidad del SW se realizan en el entorno de Validación de ICM, repitiendo las pruebas a partir de los mismos casos de pruebas que el proveedor ejecutó anteriormente. Cuando no sea posible el despliegue de la aplicación en el entorno de Validación de ICM, el RP puede tratar otras alternativas con la UOR de Calidad del SW Utilidad Confirmar que la aplicación cumple los requisitos técnicos contribuye a asegurar la confianza de ICM en que la aplicación satisfará la percepción de los usuarios como servicio de calidad. Las pruebas favorecen la aparición de errores técnicos de manera controlada al comprometer el funcionamiento de la aplicación. Reparar los errores aflorados por las pruebas en fases previas conlleva ahorros de recursos frente a hacerlo durante la explotación de la aplicación en Producción. Estas pruebas también implican probar indirectamente la arquitectura, frameworks y terceras aplicaciones con las que se integre. Estos elementos también se benefician de las pruebas porque Página 13 de 21

14 estas ayudan a localizar puntos de mejora. Más aún cuando incrementar el rendimiento en elementos como la arquitectura o frameworks redunda en mejor rendimiento en las aplicaciones que los usan. Minimizar el riesgo de desplegar sistemas sin conocer su desempeño en cuanto a rendimiento. Ayudar a localizar la causa raíz de cuellos de botella y fallos. Optimizar la experiencia de usuario mediante testeo contra los niveles de servicio para contribuir a que los ANS se cumplan en Producción. Reducir el coste de los defectos, detectándolos en etapas tempranas del ciclo de vida de la aplicación. Minimizar costes de hardware y software facilitando su valoración mediante la estimación de la capacidad y consumo de recursos de la aplicación y su arquitectura. Proporcionar estadísticas de rendimiento y capacidad, para conocer el comportamiento previsto bajo distintas condiciones de carga. Evaluar el ancho de banda, para conocer la cantidad de datos enviados y recibidos. Optimizar la aplicación a través de la evaluación comparativa en el tiempo de sucesivas versiones Modelo de prestación Alcance y ámbito tecnológico Toda aplicación, webservice, o batch resultado de un desarrollo nuevo o migración construida para ICM que siga la GGPD y cualquier otro desarrollo a criterio de la UOR de Producción. Y que el código sea de alguna de las siguientes tecnologías: JAVA Framework ATLAS. JAVA Framework2. JAVA Framework Justicia. NOTA: Ver la tabla detallada en el ANEXO de servicios disponibles Características El proveedor tiene la OBLIGACIÓN de que la aplicación cumpla los requisitos técnicos. Para ello debe actuar según la presente guía y la GGPD. Se trata de un PROCESO ITERATIVO hasta la superación SATISFACTORIA de los requisitos técnicos con un uso equilibrado de los recursos técnicos de ICM. El informe de pruebas del proveedor debe recoger los casos de prueba realizados, sus resultados y la comparativa respecto a los requisitos técnicos. Los resultados analizarán al menos para cada caso de pruebas las métricas mínimas disponibles en el documento de solicitud de pruebas dentro del Portal de Desarrollo: Página 14 de 21

15 Durante la Fase de Construcción, el proveedor está OBLIGADO a realizar pruebas de rendimiento de la aplicación, para ello el RP debe recordar al proveedor la conveniencia de probar anticipadamente cada funcionalidad completa mediante sus propios procesos y herramientas. El RP se debe asegurar de que el proyecto cuenta con su documento de casos de prueba. Los casos de prueba son elegidos por la UOR de Servicios al Cliente. Con independencia de quién y cuándo se realicen las pruebas, siempre se seguirá el documento de casos de prueba del proyecto. La unidad mínima de código sobre la que se presta el servicio de pruebas de rendimiento es el de una funcionalidad completa de la aplicación. Según la GGPD, EXCEPCIONALMENTE y siempre con la debida autorización (consultar la GGPD), se podrá solicitar el paso a producción sin la ejecución o ejecución no satisfactoria de las pruebas de rendimiento. En este caso el RP deberá a posteriori solicitar las pruebas de rendimiento siguiendo el procedimiento previsto. El RP es responsable de la ejecución de las pruebas de rendimiento satisfactorias. El procedimiento, alcance y herramientas de la UOR de Calidad del SW para las pruebas de rendimiento, pueden evolucionar según tecnología y proyecto. Las herramientas que emplea la UOR de Calidad del SW para ejecutar las pruebas son SilkPerformer, Dynatrace, SOAPUI, Jmeter. La elección en cada caso dependerá de la tecnología y características de la aplicación a probar Fases y actividades Las pruebas de rendimiento se solicitan a la UOR de Calidad del SW en las siguientes fases descritas en la GGPD: Fase de Construcción: Cuando el objetivo es probar el rendimiento de un subconjunto de funcionalidades completas. Fase de Integración y Validación: Cuando el objetivo es probar el rendimiento de toda la aplicación a través de un conjunto de casos de prueba. En ambos casos las actividades a realizar son: 1. El RP sigue la GGPD y comparte con la UOR de Calidad del SW la planificación del proyecto, y pone en su conocimiento el Plan de Entregas. Así la UOR de Calidad del SW conoce con antelación en qué casos y cuando se le va a solicitar las pruebas de rendimiento, tanto para las entregas parciales, como para la entrega final. 2. Previa a la primera instalación en Desarrollo, el proveedor realiza la revisión de código y las pruebas de rendimiento demostrando la satisfacción de los requisitos técnicos. Para cada caso de pruebas el informe de pruebas del proveedor recogerá al menos los resultados de las métricas mínimas disponibles en documento de solicitud de pruebas. Ver en el Portal de Desarrollo: 3. Siguiendo la GGPD, la aplicación es validada técnica y funcionalmente en el entorno de Desarrollo y sus módulos técnicos revisados en código de manera satisfactoria. Página 15 de 21

16 4. Seguidamente el RP gestiona la instalación de la aplicación en el entorno de Validación, así como la validación técnica y funcional. También gestiona la existencia de datos de prueba completos y suficientemente numerosos. Igualmente se asegura de la disponibilidad de usuarios de prueba y sus certificados digitales, si procede. 5. Posteriormente el RP solicita a la UOR de Calidad del SW la realización de las pruebas de rendimiento en el entorno de Validación de ICM mediante solicitud a través del Portal para el Desarrollo de Aplicaciones, ( eligiendo el proyecto CALIDAD y la categoría SOLICITUDES PRUEBAS RENDIMIENTO adjuntando: Último informe de pruebas del proveedor con las características comentadas antes. documento de solicitud de pruebas ( la especificación de los casos de prueba, hasta un máximo de 4 por solicitud. Cada caso debe explicar los requisitos técnicos mínimos para aceptar el rendimiento obtenido del caso. Al menos deben cuantificarse los requisitos: Tiempo medio para completar un usuario el caso de prueba. Por omisión se considerará un tiempo máximo de 1 minuto. Número de usuarios concurrentes, entendido como el número de usuarios que simultáneamente podrán ejecutar el caso de prueba con un tiempo de respuesta similar al tiempo medio requerido. En general se considera que toda aplicación debe al menos soportar 10 usuarios simultáneos 6. Una vez finalizadas las pruebas la UOR de Calidad del SW presenta los resultados al RP. 7. Si los resultados satisfacen los requisitos técnicos la UOR de Calidad del SW entrega el Informe de Pruebas de Rendimiento al RP de la forma: i. Si se ha empleado Subversion, la UOR de Calidad del SW copia el informe en la carpeta certificados de la etiqueta de entrega de Subversion. ii. Si NO se ha empleado Subversion, la UOR de Calidad del SW copia el informe en la misma localización de la ruta de los fuentes informada en al solicitud. El informe se identifica como IPT_[módulo técnico]_[identificador del caso]_[fecha] 8. Si el informe no confirma el cumplimiento de los requisitos técnicos con un uso equilibrado de recursos técnicos se considera que las pruebas NO fueron satisfactorias. En tal caso el RP se responsabiliza de que se apliquen las acciones correctoras necesarias. Luego comienza nuevamente otro ciclo de pruebas, y así sucesivamente hasta que el informe sea satisfactorio. Página 16 de 21

17 Participantes La UOR de Calidad del SW tiene la competencia de revisar el cumplimiento de los requisitos técnicos de la aplicación verificando la satisfacción de los mismos mediante pruebas con los casos de prueba documentados en el proyecto. El RP del nuevo desarrollo o del evolutivo. El proveedor del nuevo desarrollo o evolutivo de la aplicación Entregables El RP verifica que las pruebas de rendimiento se están haciendo y se asegura de recibir y almacenar los Informes de Pruebas de Rendimiento. El informe de pruebas de rendimiento describe cómo se comporta la aplicación analizada respecto a los requisitos técnicos informados. El RP se debe asegurar de que el Informe de Pruebas de rendimiento correspondiente a la Entrega Final satisface los requisitos técnicos. Los entregables varían atendiendo a la tecnología del código del módulo técnico y a las herramientas empleadas Tareas propias de la UOR de Calidad del SW y tiempos de servicio Una vez recibida la solicitud a través del Portal para el Desarrollo de Aplicaciones, ( eligiendo el proyecto CALIDAD y la categoría SOLICITUDES PRUEBAS RENDIMIENTO y validada su completitud, la UOR de Calidad del SW informa al peticionario del registro correcto de la solicitud. Queda en cola la solicitud mientras se atienden otras anteriores. Cuando le toca el turno, la UOR de Calidad del SW informa al RP de la fecha estimada de finalización. Al ser un proceso específico para cada petición no se anticipa una estimación de la duración, ya que las actividades varían según las necesidades de la aplicación respecto al número, complejidad y programación de los casos de prueba. La UOR de Calidad del SW trabaja estrecha y continuamente con el RP, de tal forma que este tendrá información puntual para, llegado el caso, actualizar su planificación. Una vez finalizado el proceso de pruebas de rendimiento, la UOR de Calidad del SW presenta y entrega su informe de pruebas de rendimiento al RP. El informe analiza el uso de los recursos técnicos que emplea la aplicación y el grado de cumplimiento de los requisitos técnicos. El RP puede solicitar a la UOR de Calidad del SW que no confirme el rendimiento de su aplicación cuando: El proveedor informa en su documento de pruebas de rendimiento de los casos de prueba realizados, sus resultados y la comparativa respecto a los requisitos técnicos. Los resultados Página 17 de 21

18 analizarán al menos para cada caso de pruebas las métricas mínimas disponibles en el documento de solicitud de pruebas. Los resultados demuestran que se satisfacen los requisitos técnicos El RP informa por escrito a la UOR de Calidad del SW que confirma el cumplimiento de los requisitos técnicos. En este caso la UOR de Calidad del SW puede realizar sus propias pruebas para confirmar los resultados del proveedor. Los responsables del entorno de Producción podrán considerar el informe de pruebas de rendimiento en su valoración para el despliegue. 7. ANEXOS 7.1 Relación de intervinientes en las actividades mencionadas En el apartado Términos y Definiciones se puede encontrar más información al respecto de cada interviniente. Esta es la relación, por orden alfabético: Proveedor RP UOR de Calidad del SW UOR de Arquitectura SW UOR de Servicios al Cliente UOR de Producción 7.2 Puntos de información y contacto Portal para la provisión de los servicios de Calidad del software Contenidos en materia de Calidad: Consultas: Página 18 de 21

19 7.3 Servicio idóneo según Necesidad Necesidad Servicio de la UOR de Calidad del SW Comprobar que mi código fuente está hecho según la normativa de ICM y/o las buenas prácticas. Asegurar un mantenimiento del código asumible a futuro, independiente del proveedor Asegurar que un nuevo encargo de tipo evolutivo no deteriora la calidad del código existente. Estimar el máximo de usuarios que puede aguantar la aplicación sin deteriorar la calidad del servicio. Una evaluación global de todo el sistema. Testear el rendimiento de las funcionalidades críticas de la aplicación que pueden tener mayor impacto en el negocio. Testear módulos específicos de una aplicación por separado. Determinar los tiempos de repuesta y consumo de recursos de la aplicación permanecen estables a medida que vaya pasando el tiempo. Identificar cuellos de botella en áreas específicas de la aplicación Solicitar una Revisión de Código (1) Solicitar una Revisión de Código (1) Solicitar una Revisión de Código (1) del código existente. Seguidamente se inicia el desarrollo del encargo y finalmente se vuelve a solicitar una Revisión de Código del código nuevo. El objetivo es comparar ambas revisiones para asegurar que al menos no aparecen nuevos incumplimientos. Solicitar unas Pruebas de Rendimiento Solicitar unas Pruebas de Rendimiento Solicitar unas Pruebas de Rendimiento Solicitar unas Pruebas de Rendimiento Solicitar unas Pruebas de Rendimiento Solicitar unas Pruebas de Rendimiento NOTA: Si el código está soportado por SAVT entonces emplearlo para revisar uno mismo el cumplimiento de la normativa. La certificación del cumplimiento se debe solicitar a la UOR Calidad una vez uno mismo obtuvo una revisión satisfactoria. Página 19 de 21

20 7.4 Servicios disponibles Revisión de Codigo (1) Framework Tecnología Servicio Nuevos Migraciones Evolutivos ATLAS (4) Framework2 (4) Java Java Aplicación SI SI Voluntario WebServices SI SI Voluntario Batch SI SI Voluntario Aplicación SI SI Voluntario Webservices SI SI Voluntario Batch SI SI Voluntario Aplicación SI SI Voluntario Justicia (4) Java WebServices SI SI Voluntario Batch SI SI Voluntario Forms 10g Aplicación Voluntario Voluntario Voluntario Modelo de datos Erwin v4 o v7 (4) Aplicación SI NO Voluntario Portales Joomla Aplicación SI NO Voluntario Business Objects (BO) SI NO Voluntario Documentum SI NO Voluntario Otras tecnologías (3) Pruebas de Rendimiento (2) Framework Tecnología Servicio Nuevas Migraciones Evolutivos Aplicación SI SI Voluntario ATLAS (4) Framework2 (4) Java Java WebServices SI SI Voluntario Batch SI SI Voluntario Aplicación SI SI Voluntario WebServices SI SI Voluntario Batch SI SI Voluntario Aplicación SI SI Voluntario Justicia (4) Java WebServices SI SI Voluntario Batch SI SI Voluntario Forms 10g Aplicación NO NO NO Modelo de datos Erwin v4 Aplicación o v7 (4) NO NO NO Portales Joomla Aplicación SI SI NO Business Objects (BO) NO NO NO Documentum NO NO NO Otras tecnologías (3) Página 20 de 21

21 Leyenda Servicio: Cada uno de los módulos técnicos implicados Nuevo: Módulo técnico que anteriormente no existía Migraciones: Cambio de versión del framework empleado en el módulo técnico Evolutivos: El responsable de ICM del módulo técnico tiene la obligación de optar por la calidad cumpliendo con la Guía de Proyectos y Guía de Calidad (1) En todo caso el proveedor debe entregar un código que cumpla la normativa de ICM. El informe será el proporcionado por SAVT cuando esté disponible la tecnología. La UOR de Calidad del SW audita el cumplimiento de la normativa y buenas prácticas de ICM en el código del proveedor con las siguientes características. (2) En todo caso el proveedor debe entregar informe de Pruebas de Rendimiento que confirmen el cumplimiento de los requisitos técnicos, (ver Guía de Proyectos y Guía de Calidad). La UOR de Calidad del SW audita las pruebas del proveedor en Validación según la tabla. (3) Consultar con UOR de Calidad del SW (4) Disponible SAVT 8. DOCUMENTOS RELACIONADOS DM-GPRO-0001: Guía de gestión de proyectos de desarrollo de SSII Página 21 de 21