UNIDAD 1

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

El aseguramiento de la calidad de SW es el conjunto de actividades planificadas y sistemáticas
necesarias para aportar la confianza adecuada en que el producto logrará satisfacer los requisitos
dados de calidad.

El aseguramiento de la calidad se enfoca en identificar y evaluar los defectos que pueden afectar
al SW.

Si los errores se pueden identificar de forma temprana en el proceso del SW, las características de
diseño se pueden especificar de modo que eliminarán o controlarán los peligros potenciales, al
corregir los errores mucho antes en cada etapa, es decir durante el proceso, ahorrando tiempo,
esfuerzo y recursos.

Hay 3 aspectos importantes con relación al aseguramiento de la calidad del SW.

- La calidad se construye.
- El aseguramiento de la calidad no es una tarea que se realiza en una fase particular del
ciclo de vida de desarrollo.
- Las actividades asociadas con el aseguramiento de la calidad del software deben ser
realizadas por personas que no estén involucradas en el esfuerzo de desarrollo.

SQA comprende una gran variedad de tareas:

- Participación en la descripción de SW.

- Auditar el producto para verificar el cumplimiento del proceso definido.
- Asegurar que las divergencias en el trabajo de SW sean documentadas de acuerdo a los
estándares definidos.
- Almacenar cualquier inconformidad y reportarla a la gerencia media.
- Las revisiones del proyecto se realizan durante cada paso del desarrollo del mismo.
- Gestiones de configuraciones de SW.

RELACIÓN DE LA ING. DE SW CON SQA

La ingeniería del SW es el establecimiento y uso de principios sólidos de la Ing. para obtener

económicamente un SW confiable y que funciones de modo eficiente.

Es la aplicación de u enfoque sistemático, disciplinado y cuantificable al desarrollo del SW.

DESARROLLO DE SW.
 Pequeña escala Gran escala
No precisa, no requiere Ingeniería. Necesidad de la Ingeniería.
Proceso simple Proceso complejo
Modelado Mínimo Modelado y diseño
Puede hacerlo una persona. Equipo de trabajo
Bajo costo Costo elevado
Desarrollo artesanal Gestión de proyecto

PERSPECTIVA HISTÓRICA DEL DESARROLLO DE SW

Década SW como añadido.

50 – 60 Desarrollo artesanal, lenguaje de bajo nivel.
60 – 70 SW como producto. Lenguajes compiladores.
70 – 80 SGBD, SO
90 – Actual POO, programación visual, tecnología CASE,
métodos ágiles, reutilización, interoperabilidad,
web. SOA (Arq. orientada a servicios).

PROBLEMÁTICA ACTUAL DEL SW.

- Incapacidad para estimar tiempo, costo y esfuerzo.

- Falta de calidad.
- Avance del HW.
- Necesidades más complejas.

DEFINICIÓN Y PROPÓSITO DE SQA.

SQA es un conjunto de actividades sistemáticas y planeadas para asegurar que los procesos y
productos de SW cumplen con los requerimientos, estándares y procedimientos.

PROCESOS PRODUCTOS
Diseño SW
Codificación Documentación
Test Soporte
Mantenimiento

PROPÓSITO DE SQA

Proporcionar visibilidad sobre procesos utilizados por el proyecto de SW y sobre los productos que
genera.

Objetivos

1. Planificar las actividades de aseguramiento de la calidad.

 2. Revisar y auditar objetivamente los productos y las actividades para verificar que estén
conformes con los procedimientos y estándares.
3. Proporcionar los resultados de estas revisiones o auditorías informando a la dirección.

EL GRUPO ENCARGADO DE SQA.

- Trabaja con el equipo del proyecto desde el inicio.

- Debe ser objetivo e independiente.
- Ayuda al proyecto, más que controlar sus actividades.

La actividad de SQA es el proceso de verificación de que los estándares sean aplicados

correctamente. En los proyectos pequeños esto se puede realizar por el equipo de desarrollo, pero
en proyectos grandes, un grupo específico se debe dedicar a este rol.

PROBLEMAS QUE RESUELVE SQA

Obtener un SW de calidad.

La obtención de un software de calidad implica la utilización de metodologías o procedimientos

estándares para el análisis, diseño, programación y prueba del SW que permitan uniformar la
filosofía de trabajo.

La adopción de una buena política o metodología contribuye en gran medida a lograr la calidad del
SW pero no la asegura.

Esta política debe estar sustentada en 3 principios básicos.

1) Tecnológico: Define las técnicas a utilizar en el proceso de desarrollo de SW.

2) Administrativo: Contempla las funciones de planificación y control del desarrollo de SW,
así como la organización del ambiente o centro de ingeniería del SW.
3) Ergonómico: define la interfaz entre el usuario y el ambiente automatizado.

Para controlar la calidad del SW, es necesario definir los parámetros, indicadores o criterios de
medición.

Las cualidades para medir la calidad del SW se definen en 2 categorías:

- Complejidad de programa o código.

- Complejidad de sistema o estructura.

Por lo tanto, SQA resuelve problemas como:

- Aumentar las posibilidades de éxito del proyecto.

- Funcionalidad.
- Cumplimiento.
- Usable.
Ayuda a definir parámetros de medición de la calidad del SW.

Verifica que los estándares sean aplicados correctamente.

Define un plan de monitoreo del proceso de desarrollo de SW (ciclo de vida).

PLAN DE SQA (SQAP)

El plan de aseguramiento de la calidad del SW (SQAP) define las actividades específicas a llevar a
cabo en un proyecto.

El SQAP contiene una lista de comprobación para las actividades que se deben llevar a cabo para
asegurar la calidad del producto.

En el SQAP se recogen una serie de medidas que permiten establecer el nivel de calidad de los
desarrollos en cualquier momento en relación a los parámetros de calidad establecidos en el
mismo, de modo que los gestores de proyecto puedan dar respuesta adecuada a las acciones a
tomar de acuerdo a las medidas que se recogen en el plan.

El SQAP CONTIENE:

- Propósito de plan.
- Documentación de referencia.
- Ciclo de vida.
- Gestión del proyecto.
- Documentación del proyecto.
- Estándares.
- Métricas.
- Mecanismos de revisión.
- Gestión de la configuración.
- Control de versiones.
- Entornos de desarrollo.
- Entornos de pruebas.
- Herramientas, técnicas y metodologías empleadas.
- Control de suministro de proveedores (si los hay).
- Políticas de almacenamiento, mantenimiento y conservación de documentación.
- Plan de pruebas.

CALIDAD DEL SW EN EL CICLO DE VIDA

A lo largo de los años se han construido un conjunto de metodologías, técnicas, estándares y

prácticas orientadas a la calidad, tanto del proceso de desarrollo de SW, como los resultados del
mismo.

A pesar de la indudable evolución y mejora de dichos procesos y de la calidad del desarrollo del
SW, la realidad es que los resultados dejan mucho que desear.
Una de las causas finales que se señala frecuentemente cuando se analiza este problema es que la
calidad real del SW resulta “invisible”.

Es muy fácil de medir, de identificar los puntos “rojos” que requieren cambios en la forma de
trabajo y de extraer recomendaciones prácticas para su introducción a lo largo del ciclo de vida de
desarrollo y no al final de las pruebas de aceptación, cuando normalmente ya es demasiado tarde
para hacer algo y el costo correctivo es elevado.

Actualmente, los equipos de desarrollo no cuentan con un espectro completo y consistente de

herramientas que permitan extraer información útil de código fuente y entregables asociados, de
otros productos de la actividad del equipo o de medidas obtenidas de las propias actividades de
desarrollo.

El SQA añade transparencia al ciclo de desarrollo, capturando, integrando y procesando de forma

automática las métricas extraídas de distintas herramientas y sistemas externos (analizadores,
gestores de defectos, sistemas de control de versiones, herramientas de prueba, etc).

Estas herramientas siguen un modelo de métricas en el que se integran medidas obtenidas

automáticamente del proceso de desarrollo (actividades, requisitos, defectos y cambios) y de los
elementos analizables de SW (código fuente, documentación del proyecto, scripts de construcción
y scripts de pruebas).

EL EQUIPO O GRUPO DE SQA

El equipo de SQA trabaja con la gerencia de proyectos durante los inicios del desarrollo para
establecer los planes, estándares y los procedimientos que agregarán valor al proyecto de SW y
satisfacer los problemas del proyecto y de las políticas de la organización.

Participa en establecer los planes, estándares y procedimientos.

El equipo ayuda a asegurar que se cumplan con las necesidades del proyecto y verifica que sean
usables para realizar revisiones e intervenciones durante todo el ciclo de vida.

Las revisiones del grupo de SQA proyectan las actividades y revisan el producto de trabajo de SW,
además de proveer a la gerencia la posibilidad de saber si el proyecto está de acuerdo a los planes
estándares y procedimientos establecidos.

ROLES Y RESPONSABILIDADES

Humpre en su libro “Team Software Process” proporciona un marco de trabajo que se construye
sobre la base del “Personal Software Process” con fases de desarrollo bien definidas, los productos
de SW se generan en varios ciclos, se establecen medidas estándares para la calidad del producto
y para el desempeño de los equipos y de los desarrolladores, se aplican evaluaciones por rol y del
equipo.
TSP ayuda a la conformación de equipos de trabajo bien organizados a través de roles, cada rol
está definido por un guión en el que se especifican su objetivo, sus responsabilidades en todo el
ciclo de desarrollo y la forma en que se puede evaluar su trabajo.

Los roles propuestos son:

1) Líder de proyecto:
- Objetivo: Coordinar al equipo, asegurar que todos cumplan con su trabajo (reportes de
datos).
- Responsabilidades: Metas, generar informes, dirigir reuniones, motivar al equipo.
2) Administrador de desarrollo
- Objetivo: controlar avance del proyecto (diseño, desarrollo).
- Responsabilidad: dirigir la realización de las fases siguiendo los estándares propuestos.
Integrar el trabajo de todos.
3) Administrador de la planificación
- Objetivo: Establecer el plan de trabajo y verificar su cumplimiento.
- Responsabilidades: Efectuar la planificación, asegurarse que se cumplan con el plan, recabar
mediciones, resolver riesgos.
4) Administrador de apoyo
- Objetivo: Ayudar al equipo a conseguir las herramientas necesarias para que pueda realizar
el trabajo, Gestionar la configuración.
- Responsabilidad: Conseguir lo necesario para el desarrollo del proyecto, generar un plan de
configuración, realizar la gestión de la configuración.
5) Administrador de calidad y proceso:
- Objetivo: Proponer un plan de calidad, proceso, resultado.
- Responsabilidades: Apoyar al equipo en la definición, gestionar el plan de calidad (SQA),
generar estándares para obtener un trabajo uniforme, moderar las revisiones de los
productos.

ACTIVIDADES DEL GRUPO DE SQA

La garantía de calidad de SW comprende una gran variedad de tareas diferentes, los ingenieros de
SW que realizan el trabajo técnico y un grupo de SQA que tiene la responsabilidad de la
planificación de la garantía de la calidad, supervisión, mantenimiento de registros, análisis e
informes.

Los ingenieros de SW afrontan la calidad aplicando métodos técnicos sólidos y medidas, realizando
revisiones técnicas formales y llevando a cabo pruebas de SW bien planificadas.

Las reglas del grupo de SQA tratan de ayudar al equipo de ingeniería del SW en la consecución de
un producto final de alta calidad.

El instituto de ingeniería del software recomienda el siguiente conjunto de actividades:

 1) Establecimiento de un plan de SQA para el proyecto.
El plan se desarrolla durante la planificación del proyecto y es revisado por todas las
partes interesadas.
2) Participación en el desarrollo de la descripción del proceso de SW del proyecto.
El equipo de ingeniería de SW selecciona un proceso para el trabajo que se va a realizar. El
grupo de SQA revisa la descripción del proceso para ajustarse a la política de la empresa,
los estándares (internos y externos) del SW y las demás partes del plan.
3) Revisión de las actividades de ingeniería del SW para verificar su ajuste al proceso de SW
definido.
El grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso
y verifica que se hayan realizado las correcciones.
4) Auditoría de los productos de SW designados para verificar su ajuste al proceso de SW con
los definidos como parte del proceso de SW.
El grupo de SQA revisa los productos seleccionados e informa periódicamente de los
resultados al administrador del proyecto.
5) Asegurar que las desviaciones del trabajo y los productos de SW se documentan y se
manejan de acuerdo al procedimiento establecido.
6) Registrar lo que no se ajuste a los requisitos e informar a los superiores.
Los elementos que no se ajustan a los requisitos están bajo seguimiento hasta que se
resuelven.

Además de estas actividades, el grupo SQA coordina el control, la gestión de cambios, ayuda a
recopilar y a analizar las métricas del SW.

METODOLOGÍA SQA

Las pruebas de SW son tanto un arte como una ciencia en general, en aplicaciones complejas,
como los sistemas operativos, es prácticamente imposible eliminar todos los errores antes de
liberar la versión, esto se debe a los diferentes puntos de vista y a las limitaciones de tiempo.
Diferentes aplicaciones de SW requieren distintos enfoques en lo que respecta a las pruebas.

Los métodos más comunes para el aseguramiento de la calidad son los siguientes:

1) Auditorías PPQA (Process and Product Quality Assurance)

Es la actividad de garantizar que el proceso y el product de trabajo se ajustan al plan
acordado.
2) Pruebas de Validación:
Es el acto de introducir datos, los cuales el tester sabe que son erróneos en la aplicación.
3) Comparación de datos:
Técnica que se realiza comparando los resultados de una aplicación con parámetros
específicos con los resultados de otra aplicación previamente creada, introduciendo los
mismos parámetros de manera que se obtenga un resultado exacto.
 4) Prueba de esfuerzo (Stress Testing)
Se realiza cuando el SW es utilizado de la manera más “ruda” posible en un período de
tiempo para ver si trabaja con altos niveles de carga.
5) Pruebas de Uso:
A veces conseguir usuarios que no estén familiarizados con el SW para probarlo por un
tiempo determinado, ofrece retroalimentación a los desarrolladores acerca de las
dificultades que encontraron. Esta es la mejor maneta de realizar mejoras a la interfaz.
6) Revisiones por Pares (Peer Reviews).
Son actividades efectivas para el control de la calidad. Pueden aplicarse al análisis, diseño
y codificación.
7) Revisión Técnica formal (RTF):
Es una actividad de garantía de calidad de SW. Es una revisión que incluye recorridos,
inspecciones y revisiones cíclicas.

REVISIONES POR PARES (PEER REVIEWS)

Consiste en la revisión del código de un programador por otros programadores (sus pares). Se
puede poner en práctica creando un panel que encarga de revisar periódicamente muestras de
código. En la revisión por pares se analizan o revisan factores técnicos, de procedimiento y
humanos.

Las revisiones por pares son las siguientes:

- Walkthroughs (recorridos)
- Revisiones
- Inspecciones de código

Walkthroughs

Objetivos:

- Detectar posibles defectos.

- Identificar oportunidades de mejora.
- Examinar alternativas.

El walkthrough es usado para revisar especificaciones de requerimientos o de diseño.

Procedimientos:

A partir del código regular, el walkthrough es realizado al menos una vez por cada bucle a través
del modelo espiral y se realizará en forma circular (programador i-th revisará el código del
programador 1-th+1).

Todas las deficiencias serán anotadas y utilizadas para el mejoramiento del proceso.
Durante cada código revisado en el walkthrough se tomarán dos mediciones: relativas y objetivas.
Las deficiencias relativas son: código eficiente (pocos recursos son consumidos) y código exacto
(que tan cerca está el producto con las especificaciones). Las deficiencias objetivas son: errores de
formato, nombre de variables no estandarizado, falta de documentación (comentarios en el
código) y falta de normas de codificación.

INSPECCIONES DE CÓDIGO

- No son excluyentes con el testing. Cada desarrollador puede encontrar distintos tipos de
defectos.
- No hay tiempo ni dinero para inspeccionar todo. Se suele centrar la inspección en los
módulos más críticos.
- Es recomendable realizarla después de una prueba básica.

Objetivos primarios:

- Detectar defectos.
- Elegir el camino de resolución.
- Verificar la resolución (Los defectos deben ser corregidos).

Objetivos secundarios:

- Asegurar consenso sobre el trabajo y la calidad.

- Potenciar el trabajo en equipo.
- Obtener datos para las métricas.

LA REUNIÓN

- El presentador o moderador conoce a fondo el producto.

- Los asistentes son especialistas del negocio, la tecnología usada o son conocedores de los
sistemas donde hay impacto.
- Se pueden discutir brevemente los temas planteados (problemas, sugerencias de mejora,
etc).
- Si funciona bien: Buenos resultados y buena relación calidad/esfuerzo.
- Se debe ser cuidadoso con el tiempo y el tema importante de la reunión.

ROLES DE LA REUNIÓN

Moderador

- Responsable de la inspección
- Asegura que todos estén preparados.
- Aclara las reglas.
- Hace cumplir las reglas.

Revisores
 - Buscan y describen los defectos.
- Toman decisiones para solucionar los errores.

Autor del Código (Desarrollador)

- Explica el código que él realizó.

- Responde las dudas.

Lector

- Lee el programa línea por línea.

Registrador

- Anota los defectos encontrados.

BENEFICIOS DE LA REUNIÓN

Directos

- Mayor calidad que lleva a aumentos de productividad.

- Mayor visibilidad del proceso.
- Trabajo en equipo y mejor comunicación.
- Mejora en la calidad de estándares y métodos.

REVISIONES

Se utilizará un checklist para realizar las revisiones.

REVISIÓN TÉCNICA FORMAL (RTF)

Una revisión técnica formal es una actividad de garantía de calidad del SW llevada a cabo por los
ingenieros de SW y el equipo de SQA. Los objetivos de la RTF son:

1) Descubrir errores en la función, la lógica o la implementación, de cualquier representación

del SW.
2) Verificar que el SW bajo revisión alcance sus requisitos.
3) Garantizar que el SW ha sido realizado con los estándares predefinidos.
4) Conseguir un SW desarrollado de forma uniforme.
5) Hacer que los proyectos sean manejables.

La RTF también sirve para promover la seguridad y continuidad, ya que varias personas se
familiarizarán con partes del SW que de algún modo no habían visto.

Cada RTF se lleva a cabo mediante una reunión y solo tendrá éxito si es bien planificada,
controlada y atendida.

REUNIÓN RTF
La reunión debe ajustarse a las siguientes restricciones.

Deben convocarse para la revisión entre 3 y 5 personas.

Se debe preparar por adelantado pero sin que requiera más de dos horas de trabajo por
cada persona.
La reunión debe ser menor de 2 horas.
Con las anteriores limitaciones, debe resultar obvio que cada RTF se centra en una parte
específica del SW total. Al limitar el centro de atención de la RTF la probabilidad de
descubrir errores es mayor.

Proceso

El desarrollo informa al jefe de proyecto que el producto está terminado y que requiere revisión.
El jefe de proyecto contacta con un jefe de revisión que evalúa la disponibilidad del producto,
genera copias del material y las distribuye a otros revisores. Cada revisor tomará notas para
conocer el trabajo. De forma simultánea, el jefe de revisión, analiza el producto y establece una
fecha para la reunión.

La reunión es llevada a cabo por el jefe de revisión, los revisores y el desarrollador. La reunión
comienza con una breve explicación del desarrollo para después continuar con el recorrido de la
inspección explicando el material, mientras los revisores exponen sus comentarios cuando se
descubren problemas o errores válidos, serán registrados.

Al final de la reunión los participantes deben decidir si.

1) Aceptar el producto sin posteriores modificaciones.

2) Rechazar el producto debido a los serios errores encontrados. Una vez corregidos debe
hacerse otra reunión.
3) Aceptar el producto provisionalmente. Se han encontrado errores menores que deben ser
corregidos sin necesidad de otra reunión.

REGISTRO E INFORME DE LA REVISIÓN

Durante la reunión se van registrando todas las dudas y errores que vayan surgiendo. Al final de la
reunión se resumen todas las incidencias y se genera una lista de sucesos de revisión. Además se
prepara un informe de la RTF que debe responder a 3 preguntas.

1) ¿Qué fue revisado?

2) ¿Quién lo revisó?
3) ¿Qué se descubrió y cuáles son las conclusiones?

La lista de sucesos de revisión tiene dos propósitos:

Identifica las áreas problemáticas dentro del producto.

 Sirve como lista de comprobación de puntos de acción que guían al programador para
realizar correcciones.

DIRECTRICES PARA LA REVISIÓN

Se deben establecer de antemano directrices para conducir la RTF. Las directrices más comunes
son las siguientes.

1) Revisar al producto no al productor.

2) Fijar una agenda y mantener. La RTF debe seguir un plan de trabajo concreto. El jefe de
revisión es el encargado de mantener el plan de la reunión.
3) Limitar el debate y las impugnaciones. Cuando se identifique alguna indecencia, puede o
no haber unanimidad sobre su impacto. Sin embargo no se deber perder el tiempo
debatiendo la cuestión si no que debe ser registrada y resolverse en otro momento.
4) Enunciar las áreas de problemas, pero no intentar resolver cualquier problema que se
ponga de manifiesto. La resolución de problemas deber ser propuesta para después de la
revisión.
5) Tomar notas. De preferencia, estas notas deber ser escritas en un pizarrón de forma que
puedan ser comprobadas por el resto de los revisores.
6) Limitar el número de participantes e insistir en la preparación adecuada.
7) Desarrollar una lista de comprobación para cada producto que será revisado. Esta lista
ayuda al jefe de revisión a estructurar la reunión. Se deben desarrollar listas de
comprobación para los documentos de análisis, diseño, codificación y prueba.
8) Llevar a cabo un buen entrenamiento formal de todos los revisores.
9) Disponer recursos y una agenda para las RTF para que las revisiones sean efectivas, se
deben planificar como una tarea de ingeniería del SW.
10) Repasar las revisiones anteriores. Las sesiones de información pueden ser beneficiosas
para descubrir problemas en el propio proceso de revisión. El primer producto que se haya
revisado puede establecer las propias directivas de revisión.

TÉCNICAS ASOCIADAS A SQA A NIVEL DE PROYECTO

SQA aborda principalmente 3 áreas o técnicas.

- Métricas de SW.
- Verificación y valoración.
- Gestión de la configuración.

Las técnicas de revisión de los productos de SW y las pruebas están fundamentalmente orientadas
a la detección de defectos en el SW que a la evaluación de aspectos orientados a la calidad.

Este aseguramiento de la calidad se realiza a través de modelos. Los más conocidos son los
siguientes:

- Modelo de Boehm.
 - Modelo factores/criterios&métricas.
- Marco ISO 9126.
- Paradigma GQM (Goal – Question - Metric).
- Modelo Gilb.
- Modelo CMM (Capability Maturity Model).
- Modelo SPICE (Software Process Improvement and capability Determination).

MÉTRICAS

Una métrica es una asignación de un valor y un atributo de una entidad de SW.

Clasificación de las métricas de SW:

Clasificación 1

- Métricas de producto.
- Métricas de proceso.

Clasificación 2

- Métricas basadas en atributos internos del producto.

o Medidas de estructuración de un programa.
o Métricas de complejidad.
o Métricas de cobertura de pruebas.
o Métricas de calidad y diseño.
- Métricas basadas en atributos externos del producto.
o Métricas de portabilidad.
o Métricas de defectos.
o Métricas de usabilidad.
o Métricas de Mantenibilidad.
o Métricas de Fiabilidad.
- Métricas basadas en el código fuente.
o No. de líneas de código.
o No. de líneas de comentarios.
o No. de instrucciones (funciones).
o Densidad de documentación.
- Métricas basadas en estructura de diseño.
o Relacionadas con el control intramodular.
o Relacionadas con el acoplamiento entre clases.
- Métricas para sistemas orientados a objetos.
o Acoplamiento
o Herencia.

HERRAMIENTAS DE CALIDAD
- Herramientas básicas.
o Diagrama de flujo.
o Diagrama causa – efecto.
o Checklist.
o Gráfica de control.
o Histograma.
o Diagrama de dispersión.
- Herramientas de gestión.
- Herramientas de creatividad.
- Herramientas estadísticas.
- Herramientas de diseño.
- Herramientas de medición.
- Niveles de madurez.