Garantía de Calidad

del Software (SQA)

Ing. Joffre León Veas, MAE

2017-2018
Twitter: @JoffreLeonVeas Correo: jleon@ups.edu.ec
 Tomado del texto
Ingeniería de Software
Ian Sommerville
Gestión de la Calidad
Ing. Joffre León Veas, MAE
Contenido
4.1. Tendencias de Calidad

4.2. Garantía de Calidad de Software

4.3. Impacto de los defectos de calidad de software

4.4. Garantía de Calidad estadística

4.5. Fiabilidad del software

Contenido Tendencias de Calidad

Calidad del software

Estándares de software Garantía de Calidad

de Software
Revisiones y inspecciones

Administración de la Calidad y Desarrollo Ágil

Mediciones en el software

Puntos claves

Referencias bibliográficas
Administración de la Calidad en el Software (1/2)
Se ocupa de garantizar que el nivel de calidad requerido se logra en un
producto de software.

Abarca tres preocupaciones principales:

A nivel organizativo, la gestión de calidad tiene que ver con el

establecimiento de un marco de los procesos de organización y las
normas que conduzcan a software de alta calidad.

A nivel de proyectos, la gestión de la calidad consiste en la aplicación de

los procesos de calidad específicos y comprobar que estos procesos
planificados se han seguido.
Administración de la Calidad en el Software (2/2)
Se ocupa de garantizar que el nivel de calidad requerido se logra en un
producto de software.

Tres preocupaciones principales:

A nivel de plan, la gestión de la calidad se refiere también a establecer un

plan de calidad para un proyecto. El plan de calidad debe establecer
los objetivos de calidad para el proyecto y definir qué procesos y
normas se van a utilizar.
Actividades de gestión de calidad
La Gestión de la calidad proporciona una verificación independiente en
el proceso de desarrollo de software.

El proceso de gestión de la calidad comprueba los resultados del

proyecto para asegurar que sean compatibles con las normas y objetivos
de la organización

El equipo de la calidad debería ser independiente del equipo de desarrollo,

para que puedan tener una visión objetiva del software. Esto les
permite informar sobre la calidad del software sin ser influenciado
por las cuestiones de desarrollo de software.
Gestión de la calidad y desarrollo de software

Nótese que las revisiones ocurren después de terminar

alguna actividad del proceso de desarrollo
Planificación de la calidad
En un plan de calidad se establecen las cualidades deseadas del producto
y cómo éstos son evaluadas y define los atributos más importantes de
calidad.

Además, el plan de calidad debe definir el proceso de evaluación de la

calidad a seguir.

Se debe establecer que se deben aplicar las normas de organización y, en

caso necesario, definir nuevos estándares para ser utilizado.
Planes de calidad
Estructura del plan de Calidad

● Introducción del producto;

● Planes de Producto;
● Descripciones de los procesos;
● Objetivos de calidad;
● Riesgos y gestión del riesgo.

Los Planes de calidad deben ser, documentos sucintos cortos

● Si son demasiado grandes, nadie los va a leer.

Ámbito de la Gestión de la calidad
La Gestión de la calidad es particularmente importante para los sistemas
grandes y complejos. La documentación de la calidad es un registro del
progreso y apoya la continuidad del desarrollo así como los cambios del
equipo de desarrollo.

Para sistemas más pequeños, la gestión de calidad necesita menos

documentación y debe centrarse en el establecimiento de una cultura de la
calidad.

En todo caso, las técnicas aún tienen que evolucionar cuando se utiliza el
desarrollo ágil.
La calidad del software
La calidad del software
Calidad, de manera simplista, significa que un producto debe cumplir con
su especificación.

Esto es problemático para los sistemas de software porque:

● Hay tensión entre los requisitos de calidad del cliente tales como
eficiencia, fiabilidad, etc. y los requisitos de calidad del desarrollador
tales como mantenimiento, reutilización, etc.;
● Algunos de los requisitos de calidad son difíciles de especificar de
manera inequívoca;
● Las especificaciones del software suelen ser incompletas y a menudo
inconsistentes.
La calidad del software
El enfoque puede ser “aptitud para el
uso" en lugar de la especificación de
conformidad.
La aptitud del software para el propósito
¿El software ha sido probado adecuadamente?

¿Es el software lo suficientemente confiable para ser puesto en uso?

¿Es el rendimiento del software aceptable para el uso normal?

¿Es el software utilizable?

¿Es el software bien estructurado y comprensible?

¿Se han seguido los estándares de programación y documentación en el

proceso de desarrollo?
Características no funcionales
La calidad subjetiva de un sistema de software se basa en gran medida a
sus características no funcionales.

Esto refleja la experiencia del usuario práctico - si la funcionalidad del

software no es lo que se espera, los usuarios a menudo sólo trabajan en
torno a este y mejor buscan y encuentran otras maneras de hacer lo que
quieren hacer.

Sin embargo, si el software no es confiable o es demasiado lento, entonces

es prácticamente imposible que puedan alcanzar sus metas.
Atributos de calidad del software

Seguridad Comprensibilidad Portabilidad

Seguridad Comprobabilidad Usabilidad

Confiabilidad Adaptabilidad Reusabilidad

Resistencia Modularidad Eficiencia

Robustez Complejidad Aprendibilidad

Conflictos en la Calidad
No es posible para cualquier sistema optimizar todos los atributos de
calidad, por ejemplo, la mejora de la robustez puede conducir a la pérdida de
rendimiento.

El plan de calidad, por tanto, debe definir la(s) cualidad(es) más

importante(s) de entre todos los atributos para el software que se está
desarrollando.

El plan también debe incluir una definición del proceso de evaluación de la

calidad, una forma acordada de evaluar si alguna cualidad, como el
mantenimiento o la robustez, está presente en el producto.
Proceso y producto de calidad
La calidad de un producto desarrollado está influenciada por la calidad
del proceso de producción.

Esto es importante en el desarrollo de software puesto que algunos de los

atributos de calidad del producto son difíciles de evaluar.

Sin embargo, existe una relación muy compleja y poco entendida entre
los procesos de software y calidad del producto.

La aplicación de habilidades y experiencia individuales es particularmente

importante en el desarrollo de software;

Factores externos como la novedad de la aplicación o la necesidad de un

programa de desarrollo acelerado puede afectar la calidad del producto.
Calidad basada en procesos
Cultura de la calidad
Los Directores de calidad deben tener como objetivo el desarrollo de una
"cultura de calidad", en donde todos los responsables del desarrollo de
software se hayan comprometido a lograr un alto nivel de calidad del
producto.

Ellos deben animar a los equipos a asumir la responsabilidad por la calidad de

su trabajo y el desarrollo de nuevos enfoques para mejorar la calidad.

Deben apoyar a las personas que están interesadas en los aspectos

intangibles de la calidad y fomentar un comportamiento profesional en todos
los miembros del equipo.
Estándares de software
Normas o estándares de software
Las Normas definen los atributos
necesarios de un producto o
proceso. Ellas juegan un papel muy
importante en la gestión de la
calidad.

Las normas pueden ser

internacionales, nacionales,
organizacionales o normas del
proyecto.
Importancia de las Normas
Proveen la encapsulación de las mejores prácticas -evita la repetición de
los errores del pasado.

Son un marco para definir lo que es sinónimo de calidad en un entorno

particular, es decir, la visión de calidad de la organización.

Proporcionan continuidad -el nuevo personal puede entender la

organización mediante la comprensión de las normas que se utilizan.
Normas de producto y proceso (1/3)
Las normas de productos

Aplica para el producto de software que se está desarrollando.

Incluyen estándares de documentos, tales como

● La estructura de los documentos, por ejemplo de requisitos,

● Estándares de documentación, como una cabecera de comentario
estándar para una definición de clase de objeto y
● Estándares de codificación, que definen cómo se debe utilizar un
lenguaje de programación.
Normas de producto y proceso (2/3)
Las Normas de proceso

Estos definen los procesos que se deben seguir durante el desarrollo de

software.

Las normas del proceso pueden incluir definiciones de la especificación,

diseño y procesos de validación, herramientas de apoyo al proceso y una
descripción de los documentos que se habrían de escribir durante estos
procesos.
Normas de producto y proceso (3/3)
Normas de Producto Normas de Proceso

Formulario de revisión de diseño Revisión del Diseño del comportamiento

Estructura del documento de Presentación de nuevo código para la

Requerimientos construcción del sistema

Formato de la cabecera del Método Proceso de liberación de la versión

Estilo de Programación Java Proceso de aprobación de plan de proyecto

Formato del Plan de Proyecto Proceso de control de cambio

Formulario de Requerimiento de cambio Proceso de grabación de prueba

Problemas con las normas
Pueden ser vistas como no relevantes y por tanto no ser actualizadas por
ingenieros de software.

A menudo cumplir con las normas incluyen un excesivo llenado o registro

de datos, casi de forma burocrática.

Si no están respaldadas por herramientas de software, el trabajo del

registro o el llenado las formas es a menudo tedioso pero necesario para
mantener la documentación asociada a los estándares.
Normas del desarrollo
Procura involucrar a los profesionales en el desarrollo. Los ingenieros
deben entender la lógica subyacente en un estándar.

Se debe revisar las normas y su uso con regularidad. Las normas pueden
convertirse rápidamente en obsoletas y esto reduce su credibilidad entre los
profesionales. Esto es relativo,....

Normas detalladas deberían tener el apoyo de herramientas

especializadas. El exceso de trabajo de oficina es la queja más importante
que se realiza contra las normas.

Implementación de Formularios basados en la web son lo suficientemente

buenos.
Marco de las normas ISO 9001
Es un conjunto internacional de normas que puede ser utilizado como base
para el desarrollo de sistemas de gestión de calidad.

La ISO 9001, es la más general de estas normas, se aplica a las

organizaciones que diseñan, desarrollan y mantienen los productos,
incluyendo el software, es un marco para el desarrollo de estándares de
software.

En él se establecen los principios generales de calidad, se describen los

procesos de calidad en general y se establece las normas y
procedimientos de la organización que deben ser definidos. Estos deben
ser documentados en un manual de calidad de la organización.
Procesos principales ISO 9001
Gestión ISO 9001 y la calidad
La certificación ISO 9001
Las normas y procedimientos de calidad deben ser documentados en un
manual de calidad de la organización.

Un cuerpo externo puede certificar que el manual de calidad de una

organización se ajusta a las normas ISO 9000.

Es más, algunos clientes requieren de los proveedores la certificación ISO

9000 a pesar de la necesidad de flexibilidad que aquí se reconoce cada vez
más.
La calidad del software y la ISO 9001
La certificación ISO 9001 es insuficiente, ya que define la calidad como la
conformidad con las normas.

No tiene en cuenta en la calidad, la experiencia del usuario del software.

Por ejemplo, una empresa podría definir la norma de la cobertura de
pruebas, especificando que todos los métodos en los objetos deben ser
llamados al menos una vez.

Por desgracia, esta norma puede satisfacerse mediante pruebas de

software incompletas que no incluye pruebas con diferentes parámetros
del método. Siempre y cuando se sigan los procedimientos de prueba
definidos y se tengan los registros de las prueba actualizados, la empresa
podría obtener la certificación ISO 9001.
Revisiones e inspecciones
Revisiones e inspecciones
Es una actividad emprendida para asegurar la conveniencia, adecuación
y eficacia del tema objeto de la revisión, para alcanzar unos objetivos
previamente establecidos.

En este aspecto, un grupo examina todo o parte de un proceso o sistema y

su documentación para encontrar problemas potenciales.

El Software o los documentos podrán ser "firmados" en una revisión lo

que significa que el progreso a la siguiente etapa de desarrollo ha sido
aprobado por la dirección.
Revisiones e inspecciones
Hay diferentes tipos de revisiones con diferentes objetivos establecidos, a
saber:

● Inspecciones para la detección/eliminación de defectos (producto);

● Inspecciones para la evaluación del progreso (productos y procesos);
● Revisiones de la calidad (producto y normas).
Revisiones e inspecciones
Los datos de la industria sobre revisiones del software se han recabado
durante más de dos décadas (U.S.A.) y se resume de manera cualitativa en
la gráficas que aparecen en la figura siguiente:
Revisiones e inspecciones
El trabajo efectuado cuando se utilizan revisiones se refleja pronto en el
desarrollo debido a un incremento del esfuerzo inicial para el software,
pero esta inversión temprana ofrece dividendos debido a que se reduce el
esfuerzo total necesario para hacer pruebas y correcciones.

De igual importancia se debe anotar que la fecha de entrega del desarrollo

con las revisiones incorporadas ocurre antes que la entrega que se hace
sin revisiones.

¡Las revisiones no quitan tiempo, lo ahorran!

Revisiones de calidad
Un grupo de personas examina
cuidadosamente la totalidad o parte
de un sistema de software y su
documentación asociada.

Los código, los diseños o

especificaciones, los planes de
prueba, las normas, etc.
deben/pueden ser revisados.
Fases en el proceso de revisión
Actividades previas a la revisión

Se refieren a la planificación de la revisión y preparación de la revisión

Durante la reunión de revisión

Aquí un autor del documento o programa que se está revisando debe

"caminar” a través del documento con el equipo de revisión.

Actividades posteriores a la revisión

Estas abordan los problemas y cuestiones que se han planteado durante la

reunión de revisión.
El proceso de revisión de software
Revisiones distribuidas
Los procesos sugeridos para recibir comentarios supone que el equipo de
revisión tiene una reunión cara a cara para discutir el software o los
documentos que se están revisando.

Sin embargo, los equipos de proyectos están a menudo distribuidos, a veces a

través de los países o continentes, por lo que es poco práctico para los
miembros del equipo encontrarse cara a cara.

Revisiones remotas se puede apoyar en el uso de documentos compartidos,

donde cada miembro del equipo de revisión puede anotar en el documento
sus comentarios.
Programa de inspecciones
Estas son revisiones por pares donde los ingenieros examinan los fuentes de
un sistema con el objetivo de descubrir anomalías y defectos.

Las inspecciones no requieren la ejecución del sistema así que pueden ser
realizadas antes de la implementación.

Se pueden aplicar a cualquier representación del sistema:requisitos, diseño,

datos de configuración, datos de prueba, etc.

Las revisiones por pares han demostrado ser una técnica efectiva para
descubrir errores en los programas.
Inspección de lista de verificación (checklist)
Lista de verificación o comprobación de errores comunes se deben utilizar
para manejar la inspección.

Listas de verificación de error dependientes del lenguaje de programación

reflejan los errores característicos que pueden surgir debido al lenguaje.

En general, la lista de comprobación 'más débil' , será la lista de verificación

más grande .

Ejemplos: inicializaciones, nomenclatura de constantes, bucle de terminación,

límites de matrices, etc.
Una lista de verificación de inspección (1/2)
Clase de fallos Verificación de Inspección

Fallos de datos ·¿Están todas las variables del programa inicializadas antes de contener sus valores?
·¿Se han nombrado todas las constantes?
·¿Debe ser el límite superior de las matrices igual al tamaño de la matriz o al tamaño -1?
·Si se utilizan cadenas de caracteres, ¿es un delimitador explícitamente asignado?
·¿Hay alguna posibilidad de desbordamiento de búfer?

Fallos de Control ·Para cada sentencia condicional, ¿es correcta la condición?

·¿Está cada bucle determinado para terminar?
·¿Están las sentencias compuestas entre corchetes correctamente?
·En declaraciones CASE, son todos los posibles casos contabilizados?
·Si se necesita un break después cada caso en el CASE, ¿ha sido incluido?

Fallos de Entrada/Salida ·¿Son todas las variables de entrada utilizadas?

·¿Tienen todas las variables de salida asignado un valor antes de que se emitan?
·¿Pueden las entradas inesperadas causar corrupción en la ejecución?
Una lista de verificación de inspección (2/2)
Clase de fallo Verificación de Inspección

Fallos de Interfaz
·Todas las llamadas a funciones y métodos tienen el número correcto de
parámetros?
·¿Coinciden los tipos de datos de los parámetros formales y actuales?
·¿Están los parámetros en el orden correcto?
·Si los componentes acceden a memoria compartida, ¿tienen el mismo modelo
de la estructura de la memoria compartida?

Fallos de administración
almacenamiento
del ·Si una estructura vinculada se modifica, se han asignado correctamente todos
los enlaces?
·Si se utiliza el almacenamiento dinámico, ha sido el espacio asignado
correctamente?
·¿Es el espacio descargado explícitamente después de que ya no es necesario?

Fallos de gestión de excepciones ·¿Se han tenido en cuenta todas las posibles condiciones de error?
Gestión de la calidad y el desarrollo ágil
Gestión de la calidad y el desarrollo ágil
La Gestión de la calidad en el desarrollo ágil es informal y no está basada en
documentos.

En su lugar, está basada en el establecimiento de una cultura de la calidad, en

el que todos los miembros del equipo se sienten responsables de la calidad
del software y toman acciones para asegurar que la calidad del producto se
mantiene.

La comunidad ágil es fundamentalmente opuesta a lo que ve como gastos

burocráticos innecesarios de los enfoques basados en estándares y de los
procesos de calidad que se concretan en la norma ISO 9001.
Buenas prácticas compartidas (1/2)
Compruebe antes de la entrega

Los programadores son los responsables de organizar sus propias revisiones

de código con otros miembros del equipo antes de que se compruebe el
código en la generación del sistema.

Nunca interrumpa la generación

Los miembros de equipo usuarios no deben comprobar código que hace que
el sistema falle. Los desarrolladores tienen que probar los cambios en sus
códigos contra todo el sistema y estar seguros de que éstos funcionan como
se esperaba.
Buenas prácticas compartidas (2/2)
Solucionar los problemas cuando los vea

Si un programador descubre problemas o puntos oscuros en el código

desarrollado por otra persona, pueden resolverlos éstos directamente en
lugar de referirse de nuevo al desarrollador original.
Revisiones y métodos ágiles
El proceso de revisión en el desarrollo de software ágil suele ser informal.

En Scrum, hay una reunión de revisión después de que cada iteración del
software se ha completado (una revisión del sprint), donde se pueden discutir
temas y problemas de calidad.

Por otra parte, en Extreme Programming, la programación en parejas asegura

que está siendo examinado código constantemente y que está siendo
revisado por otro miembro del equipo.
La programación por pares
Este es un enfoque en donde 2 personas son responsables del desarrollo del
código y trabajan juntos para lograrlo.

Por lo tanto, se está examinando constantemente el código desarrollado por

un individuo y es revisado por otro miembro del equipo.

La programación por pares conduce a un profundo conocimiento de un

programa, ya que los programadores tienen que comprender el programa en
detalle para continuar el desarrollo. Esta profundidad de conocimiento es
difícil de lograr en los procesos de inspección y la programación en parejas
pueden encontrar errores que no serían descubiertos en las inspecciones
formales.
Debilidades programación en parejas (1/2)
Malentendidos mutuos

Ambos miembros de una pareja pueden cometer el mismo error en la

comprensión de los requisitos del sistema. Las discusiones pueden
reforzar estos errores.

Reputación Par

Los pares pueden ser reacios a buscar los errores, ya que no quieren frenar
el avance del proyecto.
Debilidades programación en parejas (2/2)
Las relaciones de trabajo

La capacidad de la pareja para descubrir defectos es probable que se vea

comprometida por su estrecha relación de trabajo que a menudo
conduce a la renuencia a criticar a los socios de trabajo.
Agile QM y sistemas grandes (1/2)
Cuando un gran sistema está siendo desarrollado para un cliente externo,
enfoques ágiles a la gestión de calidad con un mínimo de documentación
pueden ser poco práctico.

Si el cliente es una compañía grande, puede tener sus propios procesos de

gestión de calidad y puede esperar que la compañía de desarrollo de software
informe sobre los avances de una manera que sea compatible con ellos.

Cuando hay varios equipos distribuidos geográficamente involucrados en el

desarrollo, tal vez de diferentes empresas, las comunicaciones informales
pueden ser poco prácticas.
Agile QM y sistemas grandes (2/2)
Para los sistemas de gran período de vida, si el equipo involucrado en el
desarrollo cambiará la documentación, los nuevos miembros del equipo les
puede resultar imposible entender el desarrollo.
Medición de Software
Medición de software
La Medición del software se ocupa de derivar un valor numérico para un
atributo de un producto de software o del proceso.

Esto permite realizar comparaciones objetivas entre las técnicas y procesos.

Aunque algunas empresas han introducido programas de medición, la

mayoría de las organizaciones todavía no hacen uso sistemático de medición
del software.

Hay pocas normas establecidas en esta área.

Métricas Software
Es cualquier tipo de medición que se refiere a un sistema de software,
proceso o documentación relacionada.

Ejemplos, líneas de código en un programa, el número de días-persona

necesarias para desarrollar un componente.

Permite al proceso de software y al software cuantificarse.

Puede ser utilizado para predecir los atributos del producto o para controlar
el proceso de software.

Las Métricas de producto pueden ser utilizadas para las predicciones

generales e identificar los componentes anómalos.
Tipos de métrica proceso (1/2)
El tiempo necesario para que un determinado proceso se complete

Esto puede ser el tiempo total dedicado al proceso, tiempo de calendario, el

tiempo empleado en el proceso por los ingenieros particulares, y así
sucesivamente.

Los recursos necesarios para un proceso en particular

Recursos podrían incluir esfuerzo total en días-persona, gastos de viaje o de

recursos informáticos.
Tipos de métrica proceso (2/2)
El número de ocurrencias de un evento en particular

Ejemplos de eventos que pueden ser monitoreados incluyen el número de

defectos descubiertos durante la inspección de código, el número de
cambios en los requerimientos solicitados, el número de informes de
fallos en una entrega de sistema y el número medio de líneas de código
modificadas en respuesta a unas necesidades cambiantes.
Mediciones de predicción y control
Uso de mediciones (1/2)
Para asignar un valor a los atributos de calidad del sistema

Mediante la medición de las características de los componentes del sistema,

tales como su complejidad ciclomática, y luego agregar estas mediciones, se
puede evaluar los atributos de calidad del sistema, tales como el
mantenimiento.
Uso de mediciones (2/2)
Identificar los componentes del sistema, cuya calidad es inferior al nivel
normal

Las mediciones pueden identificar los componentes individuales con

características que se desvían de lo normal.

Por ejemplo, se pueden medir componentes y descubrir los de mayor

complejidad. Estos son más probable que contengan errores debido a que la
complejidad hace que sea más difícil de entender.
Supuestos de las Métricas
Una propiedad del software puede (debe) medirse con precisión.

Existe la relación entre lo que podemos medir y lo que queremos saber. Sólo
podemos medir atributos internos, pero estamos a menudo más interesados
en los atributos externos del software.Esta relación se ha formalizado y
validado.

Puede ser difícil de relacionar lo que se puede medir y los atributos deseables
o requeridos referentes a la calidad externa.
Relaciones entre el software interno y externo
Problemas con la medición en la industria
Es imposible cuantificar el retorno de la inversión de la introducción de un
programa de métricas a nivel organizacional.

No existen estándares para las métricas de software o procesos

estandarizados para la medición y el análisis.

En muchas empresas, los procesos de software no están estandarizados y

están mal definidos y controlados.
Problemas con la medición en la industria
La mayoría del trabajo en la medición de software se ha centrado en las
métricas basadas en código y los procesos de desarrollo impulsado en planes,
sin embargo, más y más software se está desarrollando mediante la
configuración de sistemas ERP o COTS.

El término COTS hace referencia al software comercial desarrollado

previamente por terceras partes, fuera de las estrategias de desarrollo y
aplicadas durante todo el SDLC basado en estos productos comerciales.

Además, la introducción de la mediciones implica una sobrecarga adicional en

la gestión asociada a los procesos.
Ingeniería de software empírica
La medición y las métricas de software son la base de la ingeniería de
software empírica.

Esta es un área de investigación en el que los experimentos con sistemas de

software y la recopilación de datos sobre proyectos reales se ha utilizado para
formular y validar hipótesis acerca de los métodos y técnicas de ingeniería de
software.

Sin embargo, la investigación sobre la ingeniería de software empírica, no ha

tenido un impacto significativo en la práctica de la ingeniería de software. Es
difícil relacionar los resultados de la investigación genérica a un proyecto que
es diferente del estudio de investigación.
Métricas de producto
Una métrica de calidad definida debe ser considerada un predictor de la
calidad del producto.

Clases de métrica de producto:

Métricas dinámicas son recogidas por las mediciones hechas de un

programa en ejecución;

Métricas estáticas son recogidos por las mediciones realizadas de las

representaciones del sistema;
Métricas de producto
Las Métricas dinámicas ayudan a
evaluar la eficiencia y la fiabilidad

Las Métricas estáticas ayudan a

evaluar la complejidad,
comprensibilidad y facilidad de
mantenimiento.
Métricas dinámicas y estáticas
Las Métricas dinámicas están estrechamente (directamente)
relacionadas con los atributos de calidad de software:

Es relativamente fácil medir el tiempo de respuesta de un sistema, atributo

de rendimiento; o el número de fallos, atributo fiabilidad.

Las Métricas estáticas tienen una relación indirecta con los atributos de
calidad:

Se tiene que tratar de derivar una relación entre estos parámetros y

propiedades tales como la complejidad, comprensibilidad y facilidad de
mantenimiento.
Métricas estáticas de productos de software
Métrica de Software Descripción

Fan-in/Fan-out Fan-in es una medida del número de funciones o métodos que se llaman a
otra función o método (digamos X). Fan-out es el número de funciones que
son llamadas por la función X. Un valor alto para fan-in significa que X está
estrechamente unido al resto del diseño y los cambios a X tendrá extensos
efectos en cadena. Un valor alto para fan-out sugiere que la complejidad
general de X puede ser alta debido a la complejidad de la lógica de control
necesaria para coordinar los llamados componentes.

Longitud de código Esta es una medida del tamaño de un programa. Generalmente, cuanto
(Length of code) mayor sea el tamaño del código de un componente, más complejo y
propenso a errores que componente es probable que sea. Longitud de
código se ha demostrado ser uno de los indicadores más fiables para
predecir la propensión a error en los componentes.
 Métricas estáticas de productos de software
Métrica de Software Descripción

Complejidad ciclomática Esta es una medida de la complejidad del control de un programa. Esta
(Cyclomatic complexity) complejidad de control puede estar relacionado con la comprensibilidad
del programa.

Longitud de identificadores Esta es una medida de la longitud media de los identificadores, nombres
(Length of identifiers) de variables, clases, métodos, etc., en un programa. Cuanto más largo
sean los identificadores, más probabilidades hay de que sean
significativos y por tanto más comprensible el programa.

Profundidad de anidamiento Esta es una medida de la profundidad de anidamiento de instrucciones IF

condicional en un programa. Profundamente anidadas sentencias IF son difíciles de
(Depth of conditional nesting) entender y potencialmente propenso a errores.
 Suite métricas orientadas a objetos
Métrica Orientada a Objeto
Métodos ponderados por clase
(WMC)
(Weighted methods per class)
Profundidad del árbol de
herencia (DIT)
(Depth of inheritance tree)
Descripción
Es el número de métodos en cada clase, ponderados por la complejidad
de cada método. Un método simple puede tener una complejidad de 1, y
un método grande y complejo un valor mucho más alto. Cuanto mayor
sea el valor de este indicador, cuanto más compleja será la clase de
objeto. Objetos complejos son más propensos a ser difícil de entender.
Puede que no sea lógicamente coherente, por lo que no puede ser
utilizado eficazmente con superclases en un árbol de herencia.
Representa el número de niveles discretos en el árbol de herencia donde
subclases heredan atributos y operaciones (métodos) de superclases.
Cuanto más profundo es el árbol de herencia, más complejo el diseño.
Muchas clases de objetos podrían tener que ser entendidas para
comprender las clases de objetos en el árbol.
 Suite métricas orientadas a objetos
Métrica Orientada a Objeto
Número de hijos (NOC)
(Number of children)
Acoplamiento entre clases de
objetos (CBO)
(Coupling between object
classes)
Descripción
Esta es una medida del número de subclases inmediatas en una clase.
Mide la amplitud de una jerarquía de clases, mientras DIT mide su
profundidad. Un valor alto para NOC puede indicar una mayor
reutilización. Puede significar que más esfuerzo se debe hacer en la
validación de clases base, debido al número de subclases que dependen
de ellos.
Las clases están acoplados cuando los métodos en los métodos de uso de
una clase o variables de instancia definidas en una clase diferente. CBO
es una medida de cómo existe mucha acoplamiento. Un valor alto para
CBO significa que las clases son altamente dependientes, y por lo tanto es
más probable que el cambio de una clase afectará a otras clases en el
programa.
 Suite métricas orientadas a objetos
Métrica Orientada a Objeto
Respuesta a una clase (RFC)
(Response for a class)
Pérdida de cohesión en
métodos (LCOM)
(Lack of cohesion in methods)
Descripción
RFC es una medida del número de métodos que podrían ser ejecutados
en respuesta a un mensaje recibido por un objeto de esa clase. Una vez
más, RFC está relacionado con la complejidad. Cuanto mayor sea el valor
de RFC, cuanto más complejo es una clase y, por tanto, lo más probable
es que va a incluir errores.
LCM se calcula considerando pares de métodos en una clase. LCOM es la
diferencia entre el número de pares método sin atributos compartidos y el
número de pares de método con atributos compartidos. El valor de este
indicador ha sido ampliamente debatido y que existe en varias
variaciones. No está claro si realmente añade ninguna información
adicional de utilidad más allá de la proporcionada por otros indicadores.
Análisis de componentes de software
Los componente del sistema puede ser analizado por separado utilizando una
serie de métricas.

Los valores de estos indicadores pueden entonces compararse para

diferentes componentes y tal vez con los datos de medición históricos
recogidos en proyectos anteriores.

Mediciones anómalas, que se desvían significativamente de lo normal, pueden

implicar que hay problemas con la calidad de estos componentes.
El proceso de medida del producto
Ambigüedad Medición
Cuando se recogen datos cuantitativos acerca de los procesos de software y
del software, hay que analizar estos datos para entender su significado.

Es fácil malinterpretar los datos y hacer inferencias que son incorrectas.

Además, no se puede simplemente mirar a los datos por sí solos. También se

debe considerar el contexto en el que se recogieron los datos.
Sorpresas en la medición
La reducción del número de fallos en un programa conduce a un mayor
número de llamadas al servicio de asistencia

El programa es pensado como más fiable y por lo tanto tiene un mercado más
diverso amplio. El porcentaje de usuarios que llaman a la mesa de ayuda
puede haber disminuido pero el total puede aumentar;

Un sistema más fiable se utiliza de una manera diferente de un sistema donde

los usuarios trabajan alrededor de las fallas. Esto conduce a un mayor
número de llamadas al servicio de asistencia.
Contexto Software
Los Procesos y productos que se están midiendo no están aisladas de su
entorno.

El entorno empresarial está cambiando constantemente y es imposible evitar

los cambios para trabajar la práctica simplemente porque pueden hacer
comparaciones de datos no válidos.

Los datos sobre las actividades humanas no siempre pueden ser tomadas en
serio, la razón es porque algunos cambios de los valores medidos son a
menudo ambiguos. Las razones deben ser investigados en detalle antes de
poder sacar conclusiones de las mediciones que se han hecho.
Análisis del software
Análisis de software es el análisis de
sobre los datos de software para
administradores e ingenieros de
software con el objetivo de
empoderar a las personas y los
equipos de desarrollo de software
para obtener y compartir una visión
de sus datos para tomar mejores
decisiones.
Habilitadores de Análisis de Software (1/2)
La recolección automatizada de datos de usuarios por parte de las empresas
de productos de software cuando su producto es usado.

Si el software falla, la información sobre fallos y el estado del sistema se

pueden enviar a través de Internet desde el ordenador del usuario a los
servidores administrados por el desarrollador del producto.
Habilitadores de Análisis de Software (2/2)
El uso de software de código abierto disponible en plataformas como
Sourceforge y GitHub y repositorios de datos de código abierto de ingeniería
de software.

El código fuente del software de código abierto está disponible para el

análisis automatizado y éstos a veces puede estar enlazados con los datos
en el repositorio de código abierto.
Uso de herramientas Analytics
Las herramientas deben ser fáciles de usar por los gerentes pues es poco
probable que tengan experiencia con el análisis.

Las herramientas deben ser rápidas y producir salidas concisas en lugar de

grandes volúmenes de información.

Las herramientas deben hacer muchas mediciones con tantos parámetros

como sea posible. Es imposible predecir de antemano qué ideas podrían
surgir.

Las herramientas deben ser interactivas y permitir a los administradores y

desarrolladores explorar el análisis.
Estado del análisis de software
El Análisis de software sigue siendo inmaduro y es demasiado pronto para
decir qué efecto tendrá.

No sólo hay problemas generales de procesamiento de 'big data', sino que

nuestro conocimiento depende de los datos recogidos de las grandes
empresas.

Las pequeñas empresas es probable que no puedan invertir en los sistemas

de recogida de datos que se requieren para el análisis automatizado, motivo
por el cual puede que no utilicen análisis de software.
Puntos clave
La Gestión de la calidad del software se ocupa de asegurar que el software
tiene un bajo número de defectos y que alcanza los estándares requeridos de
mantenimiento, fiabilidad, portabilidad, etc.

Los estándares de software son importantes para el aseguramiento de la

calidad, ya que representan una identificación de 'mejores prácticas'.

En el desarrollo de software, las normas proporcionan una base sólida para la

construcción de software de buena calidad.
Puntos clave
Las revisiones de los entregables del proceso de software implican que un
equipo de personas comprueban que las normas de calidad se están
siguiendo.

Las revisiones son la técnica más utilizada para evaluar la calidad.

En una inspección del programa o revisión por pares, un pequeño equipo

comprueba sistemáticamente el código. Ellos leen el código en detalle y
buscan posibles errores y omisiones. Los problemas detectados se discuten
en una reunión de revisión de código.
Puntos clave
La Gestión de la calidad Agile se basa en el establecimiento de una cultura de
calidad en el que el equipo de desarrollo trabaja en conjunto para mejorar la
calidad del software.

La Medición de software puede ser utilizado para recopilar datos cuantitativos

sobre el software y el proceso de software.

Se logra la posibilidad de utilizar los valores de las métricas de software que

se recogen para hacer inferencias acerca de los productos y la calidad del
proceso.
Puntos clave
La Métricas de calidad del producto software son particularmente útiles para
poner de relieve los componentes anómalos y que pueden tener problemas
de calidad. Estos componentes deben ser analizados con más detalle.

El Análisis de software es el análisis automatizado de grandes volúmenes de

datos de los productos de software y su procesamiento para descubrir
posibles relaciones de sus atributos y/o características y que pueden
proporcionar ideas útiles a los administradores y desarrolladores de
proyectos.
Referencias bibliográficas
Sommerville Ian, Ingeniería de software, Pearson Educación, novena
edición. México. Año 2011.

Pressman Roger, Ingeniería de software, McGraw Hill Educación, séptima

edición. México. Año 2010.

Norma Internacional ISO 9000:2005 (traducción certificada). Suiza