Guía de Calidad del Software

ESPECIFICACIONES
Guía de Calidad del Software
ES-GPRO-0002-1.6
ES-GPRO-0002-1.6: Guía de Calidad del software
Participantes en el ciclo de aprobación de esta versión del documento:
Elaboradores
Alejandro Jiménez López
Consultores
Maria Eugenia Díez Crespo
Luisa Muñoz Carmona
Begoña Delgado Rico
José Antonio Peláez Pamos
(UOR de Organización)
Revisores
Aprobadores
Antonio Fernández Moreno
Margarita Gil Trinidad (UOR
de Organización)
Julia Molina Franquelo
Histórico del documento:
Nº de
Versión
1.0
1.1
1.2
1.3
1.4
1.5
1.6
Razones de los cambios respecto a la versión anterior
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)
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.
Compatibilidad con Subversion. Gestión de requisitos técnicos. Registro en
Mantis. (14/7/2014)
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)
Fecha puesta
en vigor
------10/2/2014
8/9/2014
---
25/5/2015
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
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
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
ÍNDICE
1.
INTRODUCCIÓN .................................................................................................................................. 4
2.
OBJETO DEL DOCUMENTO ............................................................................................................... 5
3.
ÁMBITO DE APLICACIÓN .................................................................................................................... 5
4.
TÉRMINOS Y DEFINICIONES ............................................................................................................. 5
4.1
Acrónimos ..................................................................................................................................... 5
4.2
Definiciones .................................................................................................................................. 6
5.
DISPOSICIONES LEGALES Y NORMATIVA ...................................................................................... 7
6.
SERVICIOS DE CALIDAD DEL SOFTWARE ...................................................................................... 7
6.1
6.1.1
Definición .................................................................................................................................. 7
6.1.2
Utilidad ...................................................................................................................................... 7
6.1.3
Modelo de prestación ............................................................................................................... 7
6.1.4
Entregables ............................................................................................................................. 12
6.1.5
Tareas propias de la UOR de Calidad del SW y tiempos de servicio .................................... 12
6.2
7.
Pruebas de rendimiento ............................................................................................................. 13
6.2.1
Definición ................................................................................................................................ 13
6.2.2
Utilidad .................................................................................................................................... 13
6.2.3
Modelo de prestación ............................................................................................................. 14
6.2.4
Entregables ............................................................................................................................. 17
6.2.5
Tareas propias de la UOR de Calidad del SW y tiempos de servicio .................................... 17
ANEXOS ............................................................................................................................................. 18
7.1
Relación de intervinientes en las actividades mencionadas ...................................................... 18
7.2
Puntos de información y contacto .............................................................................................. 18
7.2.1
Portal para la provisión de los servicios de Calidad ............................................................... 18
7.3
Servicio idóneo según Necesidad .............................................................................................. 19
7.4
Servicios disponibles .................................................................................................................. 20
DOCUMENTOS RELACIONADOS ..................................................................................................... 21
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
8.
Revisión de código estático .......................................................................................................... 7
Página 3 de 21
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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).
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
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
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
4.1
Página 5 de 21
Acrónimos
ICM
Agencia de Informática y Comunicaciones de la Comunidad de Madrid
GGPD
Guía de gestión de proyectos de desarrollo de sistemas de información (ver apartado
“Documentos relacionados”)
RP
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.
SAVT
Servicio Automático de Verificación Telemática: aplicación para la Revisión de Código en
modalidad autoservicio y automático.
SW
Software
UO
Unidad Organizativa (genérica)
UOR de …
Unidad Organizativa Responsable de … una función
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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.
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
Técnico de la empresa en cuestión que participa en cualquiera de las funciones contratadas al efecto:
análisis, codificación, pruebas, etc.
Página 6 de 21
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.
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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
6.1.1
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.
6.1.2
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.
6.1.3
Modelo de prestación
6.1.3.1 Alcance y ámbito tecnológico
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
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:
Página 7 de 21

Nuevos desarrollos de sistemas de información según la GGPD

Migración de Tecnología en Módulos de Aplicaciones.
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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.
6.1.3.2 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,
(http://www.madrid.org/arquitecturasw/consultas), 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.
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
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
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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.
6.1.3.3 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,
http://www.madrid.org/savt 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
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
perfil Responsable de Empresa para la gestión de SAVT, así como la creación de la propia empresa
Página 9 de 21
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
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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, (http://www.madrid.org/arquitecturasw/consultas), eligiendo el
proyecto CALIDAD y la categoría ‘SOLICITUDES REVISIONES CÓDIGO’ adjuntando:
a. el
formulario
según
plantilla
de
ficha
de
entrega
http://www.madrid.org/arquitecturasw/calidad/servicios/revisiones
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.
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
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.
Página 10 de 21
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.
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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,
(http://www.madrid.org/arquitecturasw/consultas), eligiendo el proyecto CALIDAD y la opción
‘SOLICITUDES REVISIONES CÓDIGO’ adjuntando:

el formulario según plantilla de la ficha de entrega
http://www.madrid.org/arquitecturasw/calidad/servicios/revisiones

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.
disponible
en
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
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
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.
6.1.3.4 Participantes
Página 11 de 21

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.
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software

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.
6.1.4
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.
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
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.
6.1.5
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,
(http://www.madrid.org/arquitecturasw/consultas), 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
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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
6.2.1
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.
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
6.2.2
Página 13 de 21
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
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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.
6.2.3
Modelo de prestación
6.2.3.1 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.
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
NOTA: Ver la tabla detallada en el ANEXO de servicios disponibles.
6.2.3.2 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: http://intranet.madrid.org/arquitecturasw/calidad/servicios/pruebas
Página 14 de 21
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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.
6.2.3.3 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.
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
En ambos casos las actividades a realizar son:
Página 15 de 21
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:
http://intranet.madrid.org/arquitecturasw/calidad/servicios/pruebas
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.
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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, (http://www.madrid.org/arquitecturasw/consultas), 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
(http://www.madrid.org/arquitecturasw/calidad/servicios/pruebas)con 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
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
misma localización de la ruta de los fuentes informada en al solicitud.
Página 16 de 21
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.
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
6.2.3.4 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.
6.2.4
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.
6.2.5
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,
(http://www.madrid.org/arquitecturasw/consultas), 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.
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
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:
Página 17 de 21

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
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
7.2.1
Página 18 de 21
Puntos de información y contacto
Portal para la provisión de los servicios de Calidad del software
Contenidos en materia de Calidad: http://www.madrid.org/arquitecturasw/calidad
Consultas: http://www.madrid.org/arquitecturasw/consultas
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
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.
Solicitar una Revisión de Código (1)
Asegurar un mantenimiento del código asumible a futuro,
independiente del proveedor
Solicitar una Revisión de Código (1)
Asegurar que un nuevo encargo de tipo evolutivo no
deteriora la calidad del código existente.
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.
Estimar el máximo de usuarios que puede aguantar la
aplicación sin deteriorar la calidad del servicio.
Solicitar unas Pruebas de Rendimiento
Una evaluación global de todo el sistema.
Solicitar unas Pruebas de Rendimiento
Testear el rendimiento de las funcionalidades críticas de
la aplicación que pueden tener mayor impacto en el
negocio.
Solicitar unas Pruebas de Rendimiento
Testear módulos específicos de una aplicación por
separado.
Solicitar unas Pruebas de Rendimiento
Determinar los tiempos de repuesta y consumo de
recursos de la aplicación permanecen estables a medida
que vaya pasando el tiempo.
Solicitar unas Pruebas de Rendimiento
Identificar cuellos de botella en áreas específicas de la
aplicación
Solicitar unas Pruebas de Rendimiento
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES

Página 19 de 21
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.
Tipo de documento: Especificación
ES-GPRO-0002-1.6: Guía de Calidad del software
7.4
Servicios disponibles
Revisión de Codigo (1)
Framework
Tecnología
Servicio
Nuevos
Migraciones
Evolutivos
Aplicación
SI
SI
Voluntario
ATLAS (4)
Java
WebServices
Batch
Aplicación
SI
SI
SI
SI
SI
SI
Voluntario
Voluntario
Voluntario
Framework2 (4)
Java
Webservices
SI
SI
Voluntario
Java
Batch
Aplicación
WebServices
Batch
Aplicación
SI
SI
SI
SI
Voluntario
SI
SI
SI
SI
Voluntario
Voluntario
Voluntario
Voluntario
Voluntario
Voluntario
SI
NO
Voluntario
SI
SI
SI
NO
NO
NO
Voluntario
Voluntario
Voluntario
Justicia (4)
Forms 10g
Modelo de datos Erwin v4
o v7 (4)
Portales Joomla
Business Objects (BO)
Documentum
Otras tecnologías (3)
Aplicación
Aplicación
Pruebas de Rendimiento (2)
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
Framework
Tecnología
ATLAS (4)
Java
Framework2 (4)
Java
Justicia (4)
Java
Forms 10g
Modelo de datos Erwin v4
o v7 (4)
Portales Joomla
Business Objects (BO)
Documentum
Otras tecnologías (3)
Página 20 de 21
Tipo de documento: Especificación
Servicio
Aplicación
Nuevas
Migraciones
Evolutivos
SI
SI
Voluntario
WebServices
Batch
Aplicación
WebServices
SI
SI
SI
SI
SI
SI
Voluntario
Voluntario
Voluntario
SI
SI
Voluntario
Batch
Aplicación
WebServices
Batch
Aplicación
Aplicación
SI
SI
SI
SI
NO
SI
SI
SI
SI
NO
Voluntario
Voluntario
Voluntario
Voluntario
NO
NO
NO
NO
Aplicación
SI
NO
NO
SI
NO
NO
NO
NO
NO
ES-GPRO-0002-1.6: Guía de Calidad del software
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 5.2.1 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
AN-02-DM-GINF-0001-3.0: Plantilla para DM, PR, IT y ES
DM-GPRO-0001: Guía de gestión de proyectos de desarrollo de SSII
Página 21 de 21
Tipo de documento: Especificación