Teoria Testing

INGENIERÍA INFORMÁTICA
CALIDAD DEL
SOFTWARE
TEMA: Conceptos
Iniciales.
Ing. David Sánchez Rivero

Concepto: la calidad se ha convertido hoy en día en uno de los
principales objetivos estratégicos para las organizaciones debido a
que, cada vez más , su supervivencia depende de la calidad de los
productos y servicios que ponen a disposición de los usuarios y
clientes y de la satisfacción de estos.
Definiciones:
Según el diccionario de la Real Academia Española, la calidad es:
1. Propiedad o conjunto de propiedades inherentes a algo, que
permiten juzgar su valor.
2. Buena calidad, superioridad o excelencia.
3. Adecuación de un producto o servicio a las características
especificadas.
4. Carácter, genio, índole.
5. Condición o requisito que se pone en un contrato.
Diversos gurús de esta área han dejado su definición de calidad
como ser:
Joseph Juran: “la palabra calidad tiene múltiples significados. Los
dos significados que dominan el uso de la palabra son: 1. La
calidad consiste en las características del producto que
satisfacen las necesidades del cliente y les proporcionan por
tanto satisfacción con el producto. 2. Calidad consiste en
ausencia de deficiencias… Es conveniente estandarizar en una
corta definición la palabra calidad como adecuación al uso”.
W. Edwards Deming: “la dificultad de definir calidad es traducir las
necesidades futuras del usuario en características medibles, de
manera que un producto pueda ser diseñado y producido para
dar satisfacción al usuario al precio que paga…”
Armand Feigenbaum: “la calidad de producto o servicio puede ser
definida como características totales compuestas de producto y
servicio de marketing, ingeniería, fabricación y mantenimiento
por medio de las cuales el producto y servicio en uso cumplirá
las expectativas del cliente”.
Calidad del Software & Testing 2
El término calidad de software se refiere al grado de desempeño de
las principales características con las que debe cumplir un sistema
computacional durante su ciclo de vida (Fig. 1), dichas
características de cierta manera garantizan que el cliente cuente
con un sistema confiable, lo cual aumenta su satisfacción frente a la
funcionalidad y eficiencia del sistema construido.
Figura 1. Ciclo de vida del software
El concepto de calidad de software, según R. Pressman se asocia a

la "concordancia con los requisitos funcionales y de rendimiento
explícitamente establecidos con los estándares de desarrollo
plenamente documentados y con las características implícitas que
se espera de todo software desarrollado profesionalmente", con
base en los requisitos funcionales y no funcionales identificados en
la etapa de análisis del sistema, insumo principal para implementar
dichos requisitos con los atributos mínimos de calidad, fomentando
la aplicación de procesos estandarizados y criterios necesarios en
cada una de sus etapas, así se fomenta que el avance en el ciclo de
vida del software minimice el riesgo de fracaso del proyecto. Por su
parte, el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE)
define calidad de software como "el grado con el que un sistema,
componente o proceso cumple los requerimientos especificados y
las necesidades o expectativas del cliente o usuario", denotando
que el énfasis radica en los requisitos específicos del sistema y en la
búsqueda de la satisfacción del cliente.

La calidad puede verse desde varios puntos de vista:
• Vista trascendental: la calidad es algo que se reconoce pero no
se define. Por lo que se puede concebir la calidad como un
ideal al que se intenta llegar, aunque no lo conseguimos debido
a deficiencias en la tecnología, en el proceso de fabricación, en
la compresión, etc. Esta vista no resulta demasiado útil para la
gestión de la calidad.
• Vista del usuario: la calidad es adecuación al propósito. Por lo
que se puede cuantificar las características de los productos,
medirlos y establecer objetivos a alcanzar.
• Vista del fabricante: la calidad es conformidad con las
especificaciones. Esta concepción de la calidad expande su
alcance para examinar la calidad durante la producción y
después de la entrega del producto. Se trata de una vista
centrada en el proceso.
• Vista basada en valor: la calidad depende de la cantidad que el
cliente esté dispuesto a pagar.
Hay que tener en cuenta que la calidad puede tener varios
orígenes:
• La calidad realizada: la que es capaz de obtener la persona que realiza el
trabajo, gracias a su habilidad en la ejecución de una tarea. Se potencia
con la mejora de las habilidades personales y técnicas de los
participantes en un proceso.
• La calidad planificada: la que se ha pretendido obtener. Es la que
aparece descrita en una especificación, en un documento de diseño o
en un plano. Es, por tanto, la que se le ha encomendado conseguir al
responsable de ejecutar el trabajo. Se potencia con la elaboración de
una especificación que sirva de buena referencia a los participantes de
un proceso.
• La calidad necesaria: la que el cliente exige con mayor o menor grado de
concreción o, al menos, la que le gustaría recibir. Se potencia con una
adecuada obtención de información de la idea de calidad de los clientes.

Conceptos relacionados con la calidad
Requisito: necesidad o expectativa establecida, generalmente
implícita u obligatoria.
Satisfacción del cliente: la percepción del cliente (que puede ser
externo o interno) sobre el grado en que se han cumplido sus
requisitos.
Capacidad de una organización, sistema o proceso: es la aptitud
para realizar un producto que cumple los requisitos para el mismo.
Conceptos relacionados con la gestión de la calidad

Política de la calidad: intenciones globales y orientaciones de una
organización relativas a la calidad tal como se expresan
formalmente por la alta dirección.
Sistema de gestión de la calidad: sistema de gestión para dirigir y
controlar una organización con respecto a la calidad.
Planificación de la calidad: parte de la gestión de la calidad
enfocada al establecimiento de los objetivos de la calidad y a la
especificación de los procesos operativos necesarios y de los
recursos relacionados para cumplir los objetivos de la calidad.
Control de la calidad: parte de la gestión de la calidad orientada al
cumplimiento de los requisitos de la calidad.
Aseguramiento de la calidad: parte de la gestión de la calidad
orientada a proporcionar confianza en que se cumplirán los
requisitos de la calidad.
Mejora de la calidad: parte de la gestión de la calidad orientada a
aumentar la capacidad de cumplir con los requisitos de la calidad.

Desde mediados del siglo pasado hasta la actualidad se han
propuesto diversos modelos para la gestión de la calidad y se han
aprobado diversas normas, varias de las cuales han sido aplicadas
en las organizaciones.
Gestión de la Calidad Total
La TQM, Total Quality Management, representa una “actitud” o
“filosofía” por la cual la organización pretende ofrecer a sus clientes
productos y servicios que satisfagan completamente sus
necesidades. Para ello se impregna la cultura de calidad en todos
los aspectos de la organización, se implementan los procesos
correctamente desde el principio y se intenta erradicar los defectos
de todo tipo de tareas.
La gestión de la calidad total concibe la organización como un
conjunto de procesos que se pueden gestionar siguiendo el ciclo
Planificar-Hacer-Verificar-Actuar que fue desarrollado por Walter
Shewhart y popularizado por W. Edwards Deming, por lo que se lo
conoce como Ciclo de Deming:
•Planificar: establecer los objetivos y procesos necesarios para
conseguir resultados de acuerdo con los requisitos del cliente
y las políticas de la organización.
•Hacer: implementar los procesos.
•Verificar: realizar el seguimiento y la medición de los
procesos y los productos respecto a las políticas, los objetivos
y los requisitos para el producto, e informar sobre los
resultados.
•Actuar: tomar acciones para mejorar continuamente el
desempeño de los procesos.
La gestión de la calidad total se basa, además, en otros principios
que persiguen la mejora continua de los procesos incorporando el
conocimiento y la experiencia de los trabajadores. Y son:
compromiso de la alta gestión con todos los empleados, reducción
de los ciclos de desarrollo, producción just in time, reducción de
costos de productos y servicios, etc.
NORMAS ISO 9000
La International Organization for Standarization nació en 1947 con
el propósito de facilitar la coordinación internacional de las normas
técnicas en los diferentes campos de la industria. Pueden ser
miembros de ISO todos los países que lo deseen, representados a
través de su organismo nacional de normalización. Por ejemplo,
ANSI (American National Standards Institute) por USA.
En algunas áreas, ISO colabora con otras organizaciones, por
ejemplo, en el campo de las tecnologías de la información forma,
junto con la IEC, el Joint Technical Commitee 1(JTC1).
El proceso de elaboración de una norma internacional, hasta su
publicación definitiva, puede ser bastante largo.
Normas sobre Calidad
La primera publicación de las normas ISO 9000 se realizó en 1987 y
cumpliendo el protocolo de ISO que obliga a que todas las normas
sean revisadas por lo menos cada cinco años.
Básicamente la norma ISO 9000 está compuesta por cuatro normas:
UNE-EN ISO 9000: Sistema de Gestión de la Calidad. Fundamentos y
vocabulario. Describe los fundamentos de los sistemas de gestión
de calidad y especifica su terminología.
UNE-EN ISO 9001: Sistema de Gestión de la Calidad. Requisitos. Esta
norma establece los requisitos para un sistema de gestión de
calidad que pueden utilizarse para su aplicación interna por las
organizaciones, para certificación o con fines contractuales. Se
centra en la eficacia.
UNE-EN ISO 9004: Gestión para el éxito sostenido de una
organización. Enfoque de gestión de la calidad. Persigue una mejora
continua de desempeño.
UNE-EN ISO 19011: Directrices para la auditoría de sistemas de
gestión de la calidad y/o medioambiental.

La familia ISO 9000 se basa en ocho principios de gestión de la
calidad que pueden ser utilizados por la dirección con el fin de
conducir a la organización hacia una mejora en el desempeño:
• Enfoque al cliente: las organizaciones dependen de sus clientes
y por lo tanto deberían comprender las necesidades actuales y
futuras de los clientes, satisfacer los requisitos de los mismos y
esforzarse en exceder sus expectativas.
• Liderazgo: los líderes establecen la unidad de propósito y la
orientación de la organización.
• Participación del personal: todo el personal es esencial para la
organización y su total compromiso posibilita que sus
habilidades sean utilizadas en beneficio de la organización.
• Enfoque basado en procesos: una ventaja de este enfoque es el
control continuo que proporciona sobre los vínculos entre los
procesos individuales dentro del sistema de procesos, así como
sobre su combinación e interacción.
• Enfoque de sistema para la gestión: identificar, entender y
gestionar los procesos interrelacionados como un sistema
contribuye a la eficiencia y eficacia de la organización en el
logro de sus objetivos.
• Mejora continua: la mejora continua del desempeño debe ser
un objetivo permanente.
• Enfoque basado en hechos para la toma de decisiones: las
decisiones eficaces se basan en el análisis de los datos y la
información.
• Relaciones mutuamente beneficiosas con el proveedor: para
crear valor entre la organización y los proveedores.

Norma ISO 9001
Esta norma internacional especifica los requisitos para un
sistema de gestión de calidad, cuando una organización:
• Necesita demostrar su capacidad para proporcionar
regularmente productos que satisfagan los requisitos del
cliente y los legales y reglamentarios aplicables.
• Aspira a aumentar la satisfacción del cliente a través de
la aplicación eficaz del sistema, incluidos los procesos
para la mejora continua del sistema y el aseguramiento
de la conformidad con los requisitos del cliente y los
legales y reglamentarios aplicables.
Todos los requisitos de esta norma internacional son
genéricos y se pretende que sean aplicables a todas las
organizaciones sin importar su tipo, tamaño y producto
suministrado.

Los modelos de calidad de software generalmente están
estructurados en factores de calidad que a su vez se componen de
criterios que son evaluados desde lo general a lo particular, y
permitir la reducción de la subjetividad en la asignación de un valor,
ya sea cuantitativo o cualitativo.
Así mismo, los modelos de calidad de software se clasifican de
acuerdo con el enfoque de evaluación, ya sea a nivel de producto,
proceso o calidad en uso.
Calidad a nivel de producto

La principal finalidad del modelo de calidad de producto es
especificar y evaluar el cumplimiento de criterios del producto, para
lo cual se aplican medidas internas y/o medidas externas. Por esta
razón, algunas normas y estándares han definido la calidad a nivel
de producto en tres tipos: interna, externa y en uso. Este enfoque
está orientado a verificar el cumplimiento de las características que
permitan alcanzar la satisfacción del cliente en cuanto a los
requisitos definidos en las etapas iniciales del proceso de
desarrollo.
Calidad a nivel de proceso

La calidad de un sistema software debe ser programada desde el
inicio del proyecto, y posteriormente en cada etapa del proceso de
desarrollo se debe llevar a cabo el control y seguimiento de los
aspectos de calidad, para minimizar los riesgos y ofrecer soporte
continuo, se garantiza así un óptimo nivel de cumplimiento de los
factores de calidad, teniendo en cuenta que si en alguna de las
etapas se deja de lado la verificación de los factores y criterios es
posible que se presente deficiencia en alguno de éstos y disminuirá
el nivel de calidad no solo del proceso, sino también del producto
en desarrollo.

Calidad en uso
Es importante resaltar que aunque en diferentes escenarios se
utilizan los términos usabilidad y calidad en uso, con el mismo
propósito y de forma intercambiable tienen significados distintos,
principalmente porque el concepto de calidad en uso es más amplio
y abarca más elementos que la usabilidad, y esta última es una de
las características de calidad de un producto software. La calidad en
uso se define como el "conjunto de atributos relacionados con la
aceptación por parte del usuario final y seguridad", y está basada
en la eficacia, productividad, seguridad y satisfacción, según ISO/IEC
9126.
Modelos a nivel de producto

McCall: Uno de los modelos pioneros en la evaluación de la calidad
de software, McCall se basa en once factores de calidad y los
mismos están organizados en tres ejes, donde el usuario puede
examinar la calidad del producto.
• Operación del Producto: se refiere a las características de
operación y los factores de calidad que integran este apartado son:
• Facilidad de Uso: por parte de los usuarios del sistema.
• Integridad: para proteger al programa de accesos que no
han sido autorizados.
• Eficiencia: en la ejecución del programa y en la utilización de
recursos por parte del mismo.
• Corrección o exactitud.
• Fiabilidad: que el sistema no falle.
• Revisión del producto: es la habilidad para ser cambiado e incluye
los siguientes factores:
• Facilidad de prueba: asegurar que el programa esté libre de
errores y conoce las especificaciones del usuario.
• Facilidad de Mantenimiento: esfuerzo requerido para
encontrar y solucionar errores que se presenten en la
operación del sistema.
• Flexibilidad: facilidad de realizar cambios.
• Transición del Producto: describe la adaptación al nuevo
ambiente e incluye los siguientes factores de calidad:
• Reusabilidad: se puede volver a usar el software.
• Portabilidad: capacidad de transferir un programa de un
ambiente a otro.
• Interoperabilidad: se puede unir a un sistema con otro.
Boehm: Es un modelo incremental, dividido en regiones de tareas y

estas a su vez en conjuntos de tareas, las cuales se ajustan a la
cantidad de iteraciones que el equipo defina, y cada iteración se
divide en cuatro sectores: planeación, análisis de riesgo, ingeniería
y evaluación.
WebQEM: es una metodología de evaluación de calidad de sitios

Web (Web-site Quality Evaluation method), diseñada para la
evaluación siguiendo seis fases: planificación y programación de la
evaluación de calidad, definición y especificación de requerimientos
de calidad, definición e implementación de la evaluación elemental,
definición e implementación de la evaluación global, análisis de
resultados, conclusión y documentación, validación de métricas.
ISO 25000: También llamadas como SQuaRE, cuyo propósito es

guiar el desarrollo con los requisitos y la evaluación de atributos de
calidad, principalmente: la adecuación funcional, eficiencia de
desempeño, compatibilidad, capacidad de uso, habilidad,
seguridad, mantenibilidad y portabilidad.

Históricamente se han desarrollado para evaluar la calidad de los
productos software diferente modelos que pretenden seguir las
directrices de calidad de otros tipos de productos: descomponer la
calidad en una categoría de características más sencillas que facilita
su estudio.
Como ya se vio uno de los modelos clásicos más utilizados es el
desarrollado por McCall, en el que la calidad de un producto
software se descompone en 11 características o factores de calidad
agrupados en tres ejes o categorías.
La evolución de estos modelos sobre calidad de producto software
lo constituye la familia ISO/IEC 25000, basada especialmente sobre
las normas ISO/IEC 9126 e ISO/IEC 14598.
Familia ISO/IEC 25000
Esta familia de normas se organiza en cinco apartados:
ISO/IEC 2500n: División de Gestión de Calidad. Las normas que
forman este apartado definen todos los modelos, términos y
definiciones comunes referenciados por todas las otras normas de
la familia 25000.
ISO/IEC 2501n: División de Modelo de Calidad. La norma de este
apartado presenta un modelo de calidad detallada incluyendo
características para calidad interna, externa y en uso.
ISO/IEC 2502n: División de Medición de Calidad. Estas normas
incluyen un modelo de referencia de la medición de la calidad del
producto, definiciones de medidas de calidad (interna, externa y en
uso) y guías prácticas para su aplicación.
ISO/IEC 2503n: División de Requisitos de Calidad. Estas normas
ayudan a especificar requisitos de calidad que pueden ser utilizados
en el proceso de licitación de requisitos de calidad del producto
software a desarrollar o como entrada al proceso de evaluación.
ISO/IEC 2504n: División de la Evaluación de Calidad. Este apartado
incluye normas que proporcionan requisitos, recomendaciones y
guías para la evaluación del producto software.

Este modelo distingue ocho características de calidad de un producto
software.
Adecuación Funcional: capacidad del producto software para
proporcionar funciones que satisfacen necesidades declaradas e
implícitas cuando se usa en las condiciones especificadas.
Se subdivide a su vez en:
• Completitud funcional: grado en el cual el conjunto de
funcionalidades cubre todas las tareas y los objetivos del
usuario especificados.
• Corrección funcional: capacidad del producto o sistema para
proveer resultados correctos con el nivel de precisión
requerido.
• Adecuación funcional: capacidad del producto software para
proporcionar un conjunto apropiado de funciones para tareas y
objetivos de usuario especificados.
Fiabilidad: capacidad de un sistema o componente para desempeñar
las funciones especificadas, cuando se usa bajo las condiciones y el
periodo de tiempo especificados.
• Madurez: capacidad del sistema para satisfacer las necesidades
de fiabilidad en condiciones normales.
• Disponibilidad: capacidad del sistema o componente de estar
operativo y accesible para su uso cuando se requiere.
• Tolerancia a fallos: capacidad del sistema o componente para
operar según lo previsto en presencia de fallos hardware o
software.
• Capacidad de recuperación: capacidad del producto software
para recuperar los datos directamente afectados y restablecer
el estado deseado del sistema en caso de interrupción o fallo.
Eficiencia de Desempeño: esta característica trata del desempeño
relativo al total de recursos utilizados bajo determinadas condiciones.

• Comportamiento temporal: los tiempos de respuesta y
procesamiento y los ratios de through de un sistema cuando
lleva a cabo sus funciones bajo condiciones determinadas en
relación con un banco de pruebas (benchmark) establecido.
• Utilización de recursos: las cantidades y tipos de recursos
utilizados cuando el software lleva a cabo sus función bajo
condiciones determinadas.
Capacidad de uso (Usabilidad): capacidad del producto software para
ser entendido, aprendido, usado y resultar atractivo para el usuario,
cuando se usa bajo determinadas condiciones.
• Capacidad para reconocer su adecuación: capacidad del producto
que permite al usuario entender si el software es adecuado para
sus necesidades.
• Capacidad para ser usado: capacidad del producto que permite al
usuario operarlo y controlarlo con facilidad.
• Protección contra errores de usuario: capacidad del sistema para
proteger a los usuarios de hacer errores.
• Estética de la interfaz de usuario: capacidad de la interfaz de
usuario de agradar y satisfacer la interacción con el usuario.
• Capacidad de aprendizaje técnico: capacidad del producto que
permite al usuario aprender su aplicación.
• Accesibilidad técnica: capacidad del producto que permite que
sea utilizado por usuarios con determinadas discapacidades.

CALIDAD DEL
SOFTWARE
TEMA: Modelos y
Normas

Seguridad: capacidad de protección de la información y los datos de
manera que personas o sistemas no autorizados no puedan leerlos
o modificarlos, y que las personas o sistemas autorizados, si.
• Confidencialidad: capacidad de protección contra el acceso de
datos e información no autorizados, ya sea accidental o
deliberadamente.
• Integridad: capacidad del sistema o componente para prevenir
accesos o modificaciones no autorizados a datos o programas
de computadora.
• No repudio: capacidad de demostrar las acciones o eventos
que han tenido lugar, de manera que dichas acciones o
acciones no puedan ser repudiados posteriormente.
• Responsabilidad: capacidad de rastrear, de forma inequívoca,
las acciones de una entidad.
• Autenticidad: capacidad de demostrar la identidad de un
sujeto o un recurso.
Compatibilidad: Capacidad de dos o más sistemas o componentes
para intercambiar información y/o llevar a cabo sus funciones
requeridas cuando compartan el mismo entorno hardware o
software.
• Coexistencia: capacidad del producto para coexistir con otro
software independiente, en un entorno común, compartiendo
recursos comunes sin detrimento.
• Interoperabilidad: capacidad de dos o más sistemas o
componentes para intercambiar información y utilizar la
información intercambiada.
Mantenibilidad: capacidad del producto software para ser
modificado efectiva y eficientemente.

• Modularidad: capacidad de un sistema o programa de
computadora que permite que un cambio en un componente
tenga un impacto mínimo en los demás.
• Reusabilidad: capacidad de un activo que permite que sea
utilizado en más de un sistema software o en la construcción
de otros activos.
• Capacidad para ser analizado: facilidad con la que se puede
evaluar el impacto de un determinado cambio sobre el resto
del software, diagnosticar las deficiencias o causas de fallos en
el software, o identificar las partes a modificar.
• Capacidad para ser modificado: capacidad del producto que
permite que sea modificado de forma efectiva y eficiente sin
introducir defectos o degradar el desempeño.
• Capacidad para ser probado: facilidad con la que se pueden
establecer criterios de prueba para un sistema o componente
y con la que se pueden llevar a cabo las pruebas para
determinar si se cumplen dichos criterios.
Portabilidad: capacidad del producto de ser transferido de forma
efectiva y eficiente de un entorno hardware, software, operacional
o de utilización a otro.
• Adaptabilidad: capacidad del producto que le permite ser
adaptado, de forma efectiva y eficiente, a diferentes entornos
determinados de hardware, software, operacionales o de uso.
• Capacidad para ser instalado: facilidad con la que el producto
se puede instalar y/o desinstalar de forma exitosa en un
determinado entorno.
• Capacidad para ser reemplazado: capacidad del producto para
ser utilizado en lugar de otro producto software determinado
con el mismo propósito y en el mismo entorno.

La norma 25010 entiende por calidad en uso la capacidad del
producto software para permitir a determinados usuarios alcanzar
determinados objetivos con efectividad, eficiencia, seguridad y
satisfacción en determinados contextos de uso.
La calidad en uso contempla las siguientes características:
Efectividad: capacidad del producto software para permitir a los
usuarios alcanzar determinados objetivos con exactitud y
completitud.
Eficiencia: esta característica considera los recursos empleados en
relación con la exactitud y completitud con las que el usuario
alcanza sus objetivos.
Satisfacción: capacidad del producto software para satisfacer a los
usuarios en un contexto de uso especificado. Se descompone, a su
vez, en:
• Nivel de agrado: capacidad de satisfacer a los usuarios
respecto a la consecución percibida de sus objetivos
pragmáticos, incluyendo resultados y consecuencias de uso
percibidas aceptables (satisfacción cognitiva).
• Placer: capacidad de satisfacer a los usuarios respecto a la
consecución percibida de sus objetivos hedónicos (de
estimulación, identificación y evocación) y las respuestas
emocionales asociadas (satisfacción emocional).
• Confort: capacidad de satisfacer a los usuarios respecto al
confort físico (satisfacción física).
• Confianza: capacidad de satisfacer al usuario al comportarse el
producto como está previsto (satisfacción con la seguridad).
Libre de riesgos: capacidad del producto o sistema para alcanzar
niveles aceptables del riesgo de hacer daño a la vida, salud o
propiedades de las personas, o al medio ambiente en un
determinado contexto de uso.

• Capacidad de mitigar el riesgo de daño económico: el grado
de impacto previsible de daño en propiedades, operaciones
comerciales o en la reputación en un determinado contexto
de uso.
• Capacidad de mitigar el riesgo para la salud y seguridad de
uso: el grado de impacto previsible de daño en personas en un
determinado contexto de uso.
• Capacidad de mitigar el riesgo de daño al medio ambiente: el
grado de impacto previsible de daño en propiedades o en el
entorno en un determinado contexto de uso.
Cobertura del contexto: capacidad del producto de ser utilizado por
determinados usuarios para conseguir sus objetivos con
efectividad, eficiencia y satisfacción en un determinado contexto de
uso.
• Conformidad con el contexto: capacidad del producto para ser
usado con efectividad, eficiencia, libre de riesgos y satisfacción
en los contextos de uso especificados.
• Flexibilidad: capacidad del producto para ser usado con
flexibilidad, eficiencia, libre de riesgos y satisfacción en
contextos no especificados en los requisitos.

La norma entiende por calidad de datos la capacidad de las
características de los datos de satisfacer necesidades explícitas e
implícitas bajo determinadas condiciones de uso. Las características
de calidad se clasifican considerando dos puntos de vista:
1. Inherente: capacidad de las características de los datos de tener
el potencial intrínseco para satisfacer las necesidades explícitas
e implícitas. Está relacionado con los aspectos del dominio
gestionados por los expertos.
Las características que se incluyen son:
• Precisión: capacidad de los datos para presentar
correctamente el valor verdadero de los atributos de un
concepto o evento.
• Compleción: capacidad de los datos asociados a una entidad
de tener valores para todos los atributos esperados e
instancias de entidad relacionadas.
• Consistencia: capacidad de los datos de estar libres de
contradicciones y de ser coherentes con otros datos.
• Credibilidad: capacidad de los datos de ser considerados
verdaderos y creíbles por los usuarios.
• Actualidad: capacidad de los datos de tener el tiempo
adecuado (la “edad correcta”).
2. Dependiente del sistema: capacidad del sistema informático de
alcanzar y preservar la calidad de los datos cuando los datos se
utilizan en determinadas condiciones. Este punto de vista suele
ser responsabilidad de los técnicos del sistema y contempla:
• Disponibilidad: capacidad de los datos de poder ser
recuperados por los usuarios y/o aplicaciones autorizados.
• Portabilidad: capacidad de los datos de poder ser
instalados, reemplazados o trasladados de un sistema a otro
preservando la calidad existente.

• Recuperabilidad: capacidad de los datos de mantener y
preservar un nivel especificado de operaciones y de calidad,
incluso en caso de fallo.
La norma establece otras características que se pueden considerar
tanto inherentes como dependientes del sistema:
• Accesibilidad: capacidad de los datos de poder ser
accedidos especialmente por personas que necesitan una
tecnología de soporte o configuración especial debido a
alguna discapacidad.
• Cumplimiento: capacidad de los datos de cumplir
estándares, convenciones o regulaciones o reglas similares
relativos a calidad de datos.
• Confidencialidad: capacidad de los datos de asegurarse que
son accesibles e interpretables por usuarios autorizados.
• Eficiencia: capacidad de los datos de ser procesados y de
proporcionar el nivel de desempeño esperado, utilizando las
cantidades y tipos de recursos apropiados.
• Precisión: capacidad de los datos de ser exactos y permitir
discriminar adecuadamente.
• Trazabilidad: capacidad de los datos de proporcionar las
pistas de auditoría sobre su acceso o modificación.
• Comprensibilidad: capacidad de los datos de poder ser
leídos e interpretados por los usuarios y de ser expresados
en los lenguajes, símbolos y unidades apropiados.

Actualmente la calidad de cualquier producto no puede ser
asegurada simplemente inspeccionando el producto por sí mismo o
desarrollando controles de calidad estadísticos. Esto se debe a que
existe una correlación directa entre la calidad del proceso y la
calidad del producto obtenido y en consecuencia, una organización
no puede garantizar la entrega de productos de calidad centrando
sus programas de calidad únicamente en el producto.
En los últimos años se han desarrollado varios ciclos de vida en
base al estudio de la producción de software como ser los modelos
cascada, evolutivo y en espiral, entre otros. Estos modelos ayudan a
comprender mejor el proceso software y determinar el orden de las
actividades necesarias en la vida de un producto software.
Sin embargo, hay una diferencia entre proceso software y ciclo de
vida. Un ciclo de vida software es un marco de referencia que
contiene los procesos, las actividades y las tareas involucradas en el
desarrollo, explotación y el mantenimiento de un producto
software, abarcando la vida del sistema desde la definición de los
requisitos hasta la finalización de su uso. Es decir define los
principios y directrices de acuerdo a las cuales se deben llevar a
cabo estas etapas. El proceso software es un concepto más amplio,
basado en el ciclo de vida y cubre todos los elementos necesarios
(tecnologías, personal, artefactos, procedimientos, etc.)
relacionados con las actividades involucradas en la vida de un
producto software.
Un proceso se define como un conjunto de actividades
interrelacionadas que transforman entradas en salidas. Un proceso
define quién está haciendo qué, cuándo y cómo alcanzar un
determinado objetivo.
Definiciones más comunes:
“Conjunto de actividades, métodos, prácticas y transformaciones
que la gente usa para desarrollar y mantener software y los
productos de trabajo asociados (planes de proyecto, diseño de

documentos, código, pruebas y manuales de usuario)” (SEI, 1995).
“Proceso o conjunto de procesos usados por una organización o
proyecto para planificar, gestionar, ejecutar, monitorizar, controlar y
mejorar sus actividades software relacionadas” (ISO, 1998).
“El proceso software define cómo se organiza, gestiona, mide,
soporta y mejora el desarrollo, independientemente de las técnicas
y métodos usados” (Derniame et al., 1999).
El proceso software es un proceso con una naturaleza especial,
determinada por las siguientes características:
• Es complejo.
• No es un proceso de producción típico, cada uno tiene
peculiaridades que lo distingue de los demás.
• No es (completamente) un proceso creativo, ya que algunas
partes pueden ser descritas en detalle y algunos
procedimientos son impuestos previamente.
• Está basado en descubrimientos que dependen de la
comunicación, coordinación y cooperación dentro de
marcos de trabajo predefinidos: los entregables generan
nuevos requisitos; los costos de cambio de software no
suelen reconocerse y el éxito depende de la implicación del
usuario y de la coordinación de muchos roles (ventas,
desarrollo técnico, cliente, etc.).
Los procesos software constan de dos subprocesos
interrelacionados:
• Proceso de producción: relacionado con la construcción y
mantenimiento del producto software.
• Proceso de gestión: que es el encargado de estimar,
planificar y controlar los recursos necesarios (personas,
tiempo, tecnología, etc.) para poder llevar a cabo y poder
controlar el proceso de producción que puede ser usado
posteriormente para mejorar el proceso y, por tanto,
mejorar la calidad del producto software.

En base a lo anterior, el proceso software es un campo de estudio
amplio y complejo en el mundo de la ingeniería del software, en el
que debido a la gran cantidad y diversidad de elementos
relacionados, se podrían establecer las siguientes categorías:
• Tecnología de Desarrollo Software: relacionado con el
soporte tecnológico, en forma de herramientas,
infraestructura y entornos.
• Métodos y Técnicas de Desarrollo Software: que constituyen
líneas guía sobre cómo se deben hacer las cosas: uso de
tecnología y realización de las actividades.
• Comportamiento Organizacional: relacionado con los
recursos humanos. Los procesos software son llevados a
cabo por equipos de personas que tienen que estar
coordinados y deben gestionarse desde una eficiente
estructura organizacional.
• Economía y Marketing: relacionado con la gestión de
proyectos, debido a que el producto software final debe
cumplir con unos plazos y costos determinados y debe
satisfacer las necesidades del cliente al que va destinado.
La integración de las tecnologías de producción y de gestión en un
entorno de trabajo constituye la esencia de la Tecnología del
Proceso Software y como resultado se han desarrollado los
Entornos de Ingeniería del Software Orientados al Proceso.
Sin embargo, la aplicación de estos entornos es lenta en la industria
por razones variadas como ser la rigidez de propuestas que han
dificultado su aplicación industrial en mercados dinámicos.
Es de esperar que esta disciplina se enseñe y practique
universalmente en la industria del software en un futuro cercano,
de tal manera que se logre que los procesos software maduren y
sean adoptados por las organizaciones.

Gestión de los Procesos Software
Los requisitos de calidad más significativos de los procesos software
son: (1) que produzcan los resultados esperados, (2) que estén
basados en una correcta definición, y (3) que sean mejorados en
función de los objetivos del negocio, muy cambiantes ante la gran
competitividad de las empresas hoy en día. Estos son los objetivos
de la Gestión del Proceso Software. La efectiva aplicación de esta
gestión es necesario asumir cuatro responsabilidades clave: Definir,
Medir, Controlar y Mejorar el Proceso.
Es decir se debe tener en cuenta los siguientes aspectos:
• Definición del Proceso: para ello es necesario modelar los
procesos, es decir, representar los elementos de interés que
intervienen.
• Ejecución y Control del Proceso: los proyectos software de
una empresa se llevan a cabo de acuerdo a los modelos de
procesos definidos. En este sentido, es importante poder
controlar, en todo momento, la ejecución de estos proyectos
(y, en consecuencia, de los procesos correspondientes) para
garantizar que se obtienen los resultados esperados.
• Medición y Mejora: existe una importante correlación entre la
medición y la mejora de los procesos software. Antes de
mejorar un proceso es necesario llevar a cabo una evaluación,
cuyo objetivo es detectar los aspectos que se pueden mejorar.
Para ello, es importante disponer de un marco de trabajo que
facilite la identificación de las entidades relevantes candidatas
a ser medidas. Con los resultados de la medición de los
procesos es posible disponer información objetiva que
permita planificar, identificar y llevar a cabo, de una manera
eficiente, las acciones de mejora necesarias.

Metamodelos de Procesos Software
Un metamodelo es un modelo explícito de los constructores y
reglas necesarias para construir modelos específicos de un
determinado dominio de interés.
Como se explicó anteriormente, para gestionar los procesos
software de una organización es muy importante definir los mismos
de forma sistemática y precisa para su posterior ejecución efectiva.
En función de los aspectos del proceso a representar será necesario
incluir unos constructores y por ello se puede encontrar una gran
diversidad de lenguajes para el modelado de procesos software.
Una propuesta es el estándar ISO/IEC 24744:2007, que establece un
marco de trabajo para la definición y extensión de metodologías de
desarrollo de software, incluyendo sus tres aspectos principales: el
proceso a seguir, los productos utilizados y generados y las
personas implicadas.
Otra propuesta es la especificación SPEM 2.0 que es un
metamodelo para definir modelos de procesos de ingeniería del
software y de ingeniería de sistemas. Se limita a incluir los
elementos mínimos necesarios para definir dichos procesos sin
añadir características específicas de un dominio o disciplina
particular. No obstante, sirve para definir métodos y procesos de
diferentes estilos, culturas, niveles de formalismo, o modelos de
ciclos de vida, por lo que se puede considerar como un lenguaje
general de modelado de procesos pero orientado a los procesos
software. El objetivo fundamental de esta especificación es tratar
de homogeneizar la diversidad terminológica existente en los
lenguajes de modelado de procesos software en los que los
mismos conceptos se tratan con diferentes.

CALIDAD DEL
SOFTWARE
TEMA: Modelos de
Calidad

CONCEPTO
El software es una de las herramientas de mayor utilidad en la
optimización de procesos en las organizaciones, con el propósito de
contar y ofrecer optimización, eficiencia y satisfacción de
necesidades, razón por la cual el software debe contar con criterios
que garanticen su calidad. De acuerdo con esta necesidad,
diferentes entidades o investigadores han propuesto estrategias,
modelos, metodologías, guías, incluso normas y estándares de
calidad que brindan apoyo al desarrollo y/o uso de un producto
software y permiten evaluar si efectivamente tiene un nivel de
calidad durante su ciclo de vida, y de esta manera fomentar un
ambiente de calidad, con base en la adecuada administración de la
información.
Un modelo de calidad de software debe ir enfocado a hacer
seguimiento y evaluación a cada etapa de construcción del
producto software. Por otro lado se menciona que los modelos de
calidad son aquellos documentos que integran la mayor parte de las
mejores prácticas, proponen temas de administración en los que
cada organización debe hacer énfasis, integran diferentes prácticas
dirigidas a los procesos clave y permiten medir los avances en
calidad.
Esta definición, enfocada a la calidad del software, identifica que la
organización debe contar con un proceso que como soporte al
mismo lleve una documentación, y se valga de distintas prácticas
definidas en el modelo, dando apoyo a la organización para tener
una mejora continua y ser más competentes, para así poder medir
la calidad y brindar productos o servicios de alto nivel.

En el ámbito de la construcción de software, el modelo de calidad
debe permitir evaluar el sistema, bien sea cualitativa o
cuantitativamente, y de acuerdo con esta evaluación la organización
podrá proponer e implementar estrategias que permitan la mejora
del proceso dentro de las etapas de análisis, diseño, desarrollo y
pruebas del software.
Modelos de calidad a nivel de producto
Modelos de calidad a nivel de proceso

McCall: Uno de los modelos pioneros en la evaluación de la calidad
de software, tiene tres etapas definidas: factores, criterios y
métricas. Los once criterios base, son: exactitud, confiabilidad,
eficiencia, integridad, usabilidad, mantenibilidad, testeabilidad,
flexibilidad, portabilidad, reusabilidad e interoperabilidad.
GQM o Goal Question Metric: Se enfoca a proporcionar una forma

que permita definir métricas para medir el avance como los
resultados de algún proyecto, a partir de la aplicación de unas
preguntas relacionadas con el proyecto, que permitan alcanzar unas
metas previamente planteadas, el modelo trabaja sobre metas,
preguntas y métricas.
Boehm: Es un modelo incremental, dividido en regiones de tareas y

estas a su vez en conjuntos de tareas, las cuales se ajustan a la
cantidad de iteraciones que el equipo defina, y cada iteración se
divide en cuatro sectores: planeación, análisis de riesgo, ingeniería
y evaluación.
FURPS: Modelo desarrollado por Hewlett-Packard, cuyo nombre

proviene de los criterios que evalúa: funcionalidad, usabilidad,
confiabilidad (reliability), desempeño (performance) y
soportabilidad.
GILB: Modelo de calidad que orienta la evaluación de software a

partir de los atributos: Capacidad de trabajo, adaptabilidad,
disponibilidad y utilizabilidad, los cuales se dividen en subatributos,
de tal manera que sirva de apoyo a la gestión de proyectos, y
proporcione una guía para solucionar problemas y detectar riesgos.

ISO 9126: Estándar basado en el modelo de McCall, dirigido a
desarrolladores, aseguradores de calidad, evaluadores, analistas y
cualquier otro involucrado en el proceso de construcción de
software. Está dividido en cuatro partes: modelo de calidad,
métricas externas, métricas internas y calidad de métricas en uso;
elementos en torno a seis características (funcionalidad, habilidad,
usabilidad, eficiencia, mantenibilidad y portabilidad) y
subcaracterísticas asociadas.
SQAE o Software Quality Assessment Exercise: Este modelo,

basado en Boehm, McCall, Dromey e ISO 9126, está orientado
principalmente a realizar evaluación por terceros que no están
directamente involucrados con el desarrollo, siguiendo tres capas:
área, factor y atributo de calidad, que permiten orientar la
evaluación jerárquicamente.
WebQEM: es una metodología de evaluación de calidad de sitios

Web (Web-site Quality Evaluation method), diseñada para la
evaluación siguiendo seis fases: planificación y programación de la
evaluación de calidad, definición y especificación de requerimientos
de calidad, definición e implementación de la evaluación elemental,
definición e implementación de la evaluación global, análisis de
resultados, conclusión y documentación, validación de métricas.
ISO 25000: También llamadas como SQuaRE, cuyo propósito es

guiar el desarrollo con los requisitos y la evaluación de atributos de
calidad, principalmente: la adecuación funcional, eficiencia de
desempeño, compatibilidad , capacidad de uso, habilidad,
seguridad, mantenibilidad y portabilidad.

ITIL: Desarrollado en el Reino Unido, con el fin de fortalecer la
gestión gubernamental, a partir de cinco elementos fundamentales:
la perspectiva del negocio, entrega del servicio, soporte del servicio,
manejo de la infraestructura y manejo de aplicaciones, con el
propósito de ofrecer una estructura integral para prestar a la
organización un servicio completo, cubriendo necesidades de apoyo
de instalación, adecuación de redes, comunicaciones, hardware,
servidores, sistema operativo, y software necesarios.
ISO/IEC 15504: Permite adaptar la evaluación para procesos en

pequeñas y medianas empresas (pymes) y grupos de desarrollo
pequeños, mediante la estructuración en seis niveles de madurez:
Nivel 0- Organización inmadura, Nivel 1- Organización básica, Nivel
2- Organización gestionada, Nivel 3- Organización establecida, Nivel
4- Organización predecible y Nivel 5- Organización optimizando. Su
objetivo es llegar a que la organización logre ser madura, lo cual
conlleva que la organización tenga procesos definidos,
responsabilidades definidas, predicción de resultados, productos
entregados con calidad, que las entregas se den en los tiempos
pactados, incrementar la productividad, clientes satisfechos, y
empleados felices.
Bootstrap: Metodología de evaluación que permite la mejora de

procesos a partir de seis actividades básicas: Examinar la necesidad,
Iniciar proceso de mejora, preparación y dirección de la evaluación,
análisis de resultados, implantación y finalización de mejoras.

Dromey: Es un modelo adaptable a evaluar varias etapas del
proceso de desarrollo como levantamiento de requisitos, diseño e
implementación. Se estructura con características y
subcaracterísticas de calidad; propone tres modelos distintos para
cada etapa de construcción del producto: modelo de
requerimientos, modelo de diseño y modelo de calidad de la
implementación, a partir de la evaluación establecida en cinco
etapas, para características como: eficiencia, confiabilidad,
mantenibilidad, portabilidad, facilidad de uso y funcionalidad.
Personal Software Process (PSP): Este modelo está enfocado al

desarrollo profesional del ingeniero, fomentando una adecuada
administración de calidad de los proyectos de desarrollo, reducción
de defectos del producto, estimación y planeación del trabajo.
Team Software Process (TSP): TSP es la fase posterior de PSP, está

diseñado para el trabajo de equipos de desarrollo de software
autodirigidos, que se orienta al desarrollo de productos con el
mínimo de defectos en tiempo y costos estimados. Cuenta con
planes detallados y procesos como revisiones personales,
inspecciones e índices de desempeño de calidad, y el fomento de la
integración del equipo.
IEEE/EIA 12207: Este estándar establece un marco de trabajo

común para el ciclo de vida del desarrollo de software, a partir del
planteamiento de procesos, actividades y tareas que pueden ser
aplicadas durante la adquisición, suministro, desarrollo, operación,
mantenimiento y/o despliegue de un producto software.

Cobit 4.0: Se caracteriza por ser orientado a negocios y proceso,
además de ser basado en controles, trabaja con siete criterios de
información que son definidos como requerimientos de control del
negocio: efectividad, eficiencia, confidencialidad, integridad,
disponibilidad, cumplimiento y confiabilidad.
ISO 90003: Conjunto de estándares utilizados para el desarrollo,

suministro y soporte del software, cuyo propósito es ofrecer una
guía de aplicación de la norma 9001 que pretende ser utilizada para
demostrar o soportar que la entidad está en capacidad de
desarrollar software con criterios de calidad.
CMMI (Capability Maturity Model Integration): Es de los modelos

más utilizados en las empresas de construcción de software, con el
propósito de verificar el cumplimiento de estándares de calidad a
partir de la medición con niveles de madurez. Este modelo se
representa de dos maneras: escalonada y continua, donde el
modelo escalonado está dirigido al software y permite clasificar las
organizaciones en cinco tipos de nivel establecidos: Inicial,
gestionado, definido, gestionado cuantitativamente y en
optimización; y por su parte el modelo continuo se enfoca al
análisis de la capacidad de cada proceso inmerso en las áreas de la
ingeniería de sistemas y lo clasifica en uno de los siguientes seis
niveles: Incompleto (0), ejecutado (1), gestionado (2), definido (3),
cuantitativamente gestionado (4) y en optimización (5).
ISO/IEC 20000: El objetivo principal de esta norma es el de avalar

que la prestación de servicios gestionados de TI de una empresa
cuentan con la calidad necesaria para brindar dichos servicios a los
clientes. Se subdivide en dos partes: "Especificaciones", publicada
como ISO 200001:2005, y "Código de buenas prácticas" publicada
como ISO 20000-2:2005.

Modelos ISO/IEC
Con las siglas ISO e IEC se está haciendo referencia a los organismos
de normalización internacionales, ya que:
• ISO es la Organización Internacional de Normalización,
(International Organization for Standardization).
• IEC hace referencia a la Comisión Electrotécnica
Internacional (International Electrotechnical Commission).
Cuando se hace referencia a la sigla UNE, se indica que las normas
cuentan con traducciones oficiales al castellano, publicadas por
AENOR (Asociación Española de Normalización y Certificación),
como es el caso de la Normas UNE-ISO/IEC 20000 que fue en junio
de 2007.
Normas ISO 9000

El protocolo ISO obliga que todas las normas sean revisadas, por lo
menos, cada cinco años. Actualmente, la familia de Normas ISO
9000 está compuesta de cuatro normas:
• UNE-EN ISO 9000. Sistemas de gestión de la calidad. Fundamentos
y vocabulario: esta norma describe los fundamentos de los sistemas
de gestión de la calidad y especifica su terminología.
• UNE-EN ISO 9001. Sistemas de gestión de la calidad. Requisitos:
especifica los requisitos para un sistema de gestión de la calidad
que pueden utilizarse para su aplicación interna por las
organizaciones, para certificación o con fines contractuales. Se
centra en la eficacia del sistema de gestión de la calidad para dar
cumplimiento a los requisitos del cliente.
• UNE-EN ISO 9004. Gestión para el éxito sostenido de una
organización. Enfoque de gestión de la calidad: proporciona
orientación sobre un rango más amplio de objetivos de un sistema
de gestión de la calidad que la Norma ISO 9001, especialmente para
la mejora continua del desempeño y de la eficiencia global de la
organización, así como de su eficacia.

UNE-EN ISO 19011. Directrices para la auditoría de sistemas de
gestión de la calidad y/o medioambiental: proporciona directrices
básicas para la realización de una auditoría conjunta de ISO 9001 e
ISO 14001.
La familia de normas ISO 9000 se basa en ocho principios de gestión
de la calidad que pueden ser utilizados por la dirección con el fin de
conducir, a la organización, hacia una mejora de desempeño:
• Enfoque al cliente: las organizaciones dependen de sus clientes y
por lo tanto deberían comprender las necesidades actuales y
futuras de los clientes, satisfacer los requisitos de los mismos y
esforzarse en exceder sus expectativas.
• Liderazgo: los líderes establecen la unidad de propósito y la
orientación de la organización. Deberían crear y mantener un
ambiente interno, en el cual el personal pueda llegar a involucrarse
totalmente en el logro de los objetivos de la organización.
• Participación del personal: el personal, a todos los niveles, es la
esencia de una organización y su total compromiso posibilita que
sus habilidades sean usadas para el beneficio de la organización.
• Enfoque basado en procesos: promueve la adopción de un
enfoque basado en procesos cuando se desarrolla, implementa y
mejora un sistema de gestión de la calidad. Establece que los
clientes juegan un papel significativo para definir los requisitos
como elementos de entrada. El seguimiento de la satisfacción del
cliente requiere la evaluación de la información relativa a la
percepción del cliente acerca de si la organización ha cumplido sus
requisitos.
• Enfoque de sistema para la gestión: identificar, entender y
gestionar los procesos interrelacionados como un sistema,
contribuye a la eficacia y eficiencia de una organización en el logro
de sus objetivos.
• Mejora continua: la mejora continua del desempeño global de la
organización debería ser un objetivo permanente de ésta.

• Enfoque basado en hechos para la toma de decisiones: las
decisiones eficaces se basan en el análisis de los datos y la
información.
• Relaciones mutuamente beneficiosas con el proveedor: una
organización y sus proveedores son interdependientes, y una
relación mutuamente beneficiosa aumenta la capacidad de ambos
para crear valor.
Norma ISO 9001

Esta norma internacional especifica los requisitos para un sistema
de gestión de la calidad, cuando una organización:
• Necesite demostrar su capacidad para proporcionar regularmente
productos que satisfagan los requisitos del cliente y los legales y
reglamentos aplicables.
• Aspira a aumentar la satisfacción del cliente a través de la
aplicación eficaz del sistema, incluidos los procesos para la mejora
continua del sistema y el aseguramiento de la conformidad con los
requisitos del cliente y los legales y reglamentos aplicables.
Todos los requisitos de esta norma son genéricos y se pretende que

sean aplicables a todas las organizaciones sin importar su tipo,
tamaño y producto suministrado.
La nueva revisión de la norma se denomina ISO 9001:2015 y sus
componentes clave son:
• Se fundamenta en tres pilares: gestión de riesgos, Sistema de
Gestión de Calidad (SGC) y estructura funcional de la empresa.
• El análisis de riesgos pasa a tener una importancia capital en la
filosofía de la norma. En este sentido, la identificación de riesgos se
considera un tema prioritario.
• Se potencia la interconexión y la relaciones entre los distintos
elementos y factores de influencia de la norma.

• Se tiene en consideración la influencia, en la empresa, del entorno
social y económico.
• La Alta Dirección pierde protagonismo en favor del nivel
competencial de todo el personal y del contexto de organización.
Norma ISO/IEC 15504

Es una norma internacional para establecer y mejorar la capacidad
y madurez de los procesos de las organizaciones en la adquisición,
suministro, desarrollo, operación, evolución y soporte de productos
y servicios. Proporciona un marco de trabajo para la evaluación que
asegure la repetibilidad y la consistencia de las valoraciones
obtenidas. La norma ISO/IEC 15504, también conocido como
Software Process Improvement Capability Determination,
abreviado SPICE, en español, «Determinación de la Capacidad de
Mejora del Proceso de Software» es un modelo para la mejora,
evaluación de los procesos de desarrollo, mantenimiento de
sistemas de información y productos software.
Consta de las siguientes partes:
• Parte 1: Conceptos y guía de introducción.
• Parte 2: Un modelo para la administración de procesos.
• Parte 3: Realización de la evaluación.
• Parte 4: Guía para conducir las evaluaciones.
• Parte 5: Construcción, selección y uso de las herramientas e
instrumentos de evaluación.
• Parte 6: Cualificación y entrenamiento de los asesores.
• Parte 7: Guía para usarse en el mejoramiento de los procesos.
• Parte 8: Guía para usarse en la determinación de la capacidad de
procesos de terceros.
• Parte 9: Vocabulario.
ISO/IEC TR 15504 es independiente de la organización, modelo del

ciclo de vida, metodología y tecnología.

Estructura de la Norma ISO/IEC 15504
ISO/IEC 15504-1. CONCEPTOS Y GUIA INTRODUCTORIA: Esta parte
es informativa, da los lineamientos generales del ISO/IEC 15504
describiendo como las partes del modelo trabajan en conjunto,
brindando así una guía para su selección y uso.
ISO/IEC 15504-2. UN MODELO DE REFERENCIA DE PROCESOS Y

CAPACIDAD DE PROCESOS: Es una parte normativa, que define
conceptualmente un modelo bidimensional, que permite evaluar
los procesos y sus habilidades para determinar la calidad del
mismo. De esta forma el modelo propuesto queda definido en
términos de entradas y salidas, y un marco de evaluación de ellas.
ISO/IEC 15504-3. REALIZACIÓN DE LA EVALUACIÓN: Es una parte

normativa, que define los requerimientos para llevar a cabo una
evaluación y certificación, de forma tal que el resultado generado
sea repetible, confiable y consistente.
ISO/IEC 15504-4. GUÍA PARA CONDUCIR LAS EVALUACIONES: Es una
parte informativa, que define una guía para llevar a cabo la
evaluación de un proceso de software, siendo amplia y flexible para
ser aplicado a diferentes modelos de organizaciones.
ISO/IEC 15504-5. CONSTRUCCIÓN, SELECCIÓN Y USO DE LAS

HERRAMIENTAS E INSTRUMENTOS DE EVALUACIÓN: Es una parte
informativa, que proporciona un ejemplo acorde a la parte 2 del
modelo, para de esta manera realizar la evaluación de un proceso,
contemplando un conjunto específico de indicadores de
capacidades y habilidades del proceso.
ISO/IEC 15504-6. CUALIFICACIÓN Y ENTRENAMIENTO DE LOS

ASESORES: Es una parte informativa, que describe las habilidades,
educación, experiencia y características de las personas
involucradas en el proceso de evaluación.
ISO/IEC 15504-7. GUÍA PARA USO EN EL MEJORAMIENTO DE LOS

PROCESOS: Es una parte informativa, donde se describe cómo
definir las entradas al modelo así como usar las conclusiones con el
único propósito de obtener una mejora en el proceso.
ISO/IEC 15504-8. GUÍA PARA USO EN LA DETERMINACIÓN DE LA

CAPACIDAD DE PROCESOS DE TERCEROS: Es una parte informativa,
es una guía donde se describe aspectos a usarse para determinar la
capacidad de los procesos de proveedores o terceros.
ISO/IEC 15504-9. VOCABULARIO: Es una parte informativa, la que

contiene el vocabulario de los términos usados en las diferentes
partes del estándar.

ISO/IEC 33000
La familia de normas ISO/IEC 33000 proporciona un marco de
trabajo coherente para la evaluación de procesos software que
sustituye las diferentes partes de la norma ISO/IEC 15504.
El propósito de la serie de estándares ISO/IEC 33000 es
proporcionar un enfoque estructurado para la evaluación de
procesos, permitiendo a las organizaciones lograr distintos
objetivos:
• Comprender el estado de sus propios procesos buscando la
mejora de los mismos.
• Determinar la idoneidad de sus propios procesos para un
requerimiento en particular o para un conjunto de requerimientos.
• Determinar la idoneidad de los procesos de otra organización para
un contrato específico o para un conjunto de contratos.
Niveles y Procesos
Los modelos de madurez organizacional agrupan los procesos del
modelo de referencia en conjuntos predefinidos de procesos para
definir un camino de mejora sucesivo e incremental para una
organización. Cada uno de estos conjuntos hace parte de cada nivel
de madurez definido por el modelo, y cada nivel proporciona un
conjunto de procesos que definen los diferentes comportamientos
de la organización.
Teniendo en cuenta estas consideraciones, el modelo para evaluar
la madurez establece como alcance cinco niveles de madurez para
clasificar el desarrollo de software de las organizaciones, desde el
nivel 1 hasta el nivel 5, siendo el 1 el nivel inferior y el 5 el superior.
Nivel 1: Básico
Los procesos valorados en la organización alcanzan el nivel de
capacidad 1, es decir, demuestran el logro del propósito de los
procesos. Los procesos son identificados y existen los productos de
trabajo de su ejecución.

Los procesos definidos para el nivel 1 son los indicados a
continuación.
• Proceso de Implementación
• Proceso de Planificación del Proyecto
Nivel 2: Gestionado
Los procesos definidos para el nivel de madurez organizacional 2
alcanzan el nivel de capacidad 2, es decir, la organización demuestra
la gestión de la ejecución de sus procesos (planificación,
supervisión y ajuste) y de los productos de trabajo asociados (están
debidamente documentados, establecidos, controlados y
mantenidos).
continuación.
• Proceso de Suministro
• Proceso de Gestión del Modelo de Ciclo de Vida
• Proceso de Evaluación y Control del Proyecto
• Proceso de Medición
• Proceso de Definición de Necesidades y Requisitos de
stakeholders
• Proceso de Gestión de la Configuración
• Proceso de Aseguramiento de la Calidad
Nivel 3: Establecido
Los procesos definidos para el nivel de madurez organizacional 2 y 3
alcanzan el nivel de capacidad 3, es decir, la organización demuestra
la efectiva definición, mejora, despliegue y aseguramiento de sus
procesos.
continuación.
• Proceso de Gestión de la Decisión
• Proceso de Gestión de Infraestructuras

• Proceso de Gestión de Recursos Humanos
• Proceso de Gestión de Riesgos
• Proceso de Verificación del Software
• Proceso de Validación del Software
• Proceso de Definición de Requisitos Sistema/Software
• Proceso de Definición de la Arquitectura
• Proceso de Integración
Nivel 4: Predecible
Los procesos definidos para el nivel de madurez organizacional 2, 3
y 4 alcanzan el nivel de capacidad 3, y algunos de estos procesos
que la organización considera debe controlar cuantitativamente
debido a sus objetivos de negocio alcanzan el nivel de capacidad 4.
Es decir, la organización demuestra un efectivo análisis y control
cuantitativo de los procesos que considera son fundamentales para
la consecución de sus objetivos de negocio. Para ello, las
necesidades de gestión cuantitativa son identificadas, los datos de
medición son recogidos y analizados para identificar las causas de
variación asignables. Se toman acciones correctivas para tratar las
causas asignables de la variación.
continuación.
• Proceso de Gestión del Portfolio
Nivel 5: Innovado
Los procesos definidos para el nivel de madurez organizacional 2, 3,
4 y 5 alcanzan el nivel de capacidad 3, y los procesos que la
organización controla cuantitativamente en el nivel anterior o los
propios de este nivel alcanzan el nivel de capacidad 5. Es decir, la
organización demuestra innovación de estos procesos y su
correspondiente implementación de la innovación en los procesos
que considera fundamentales para conseguir sus objetivos de
negocio.
continuación.
• Proceso de Gestión de Conocimiento
• Proceso de Análisis de Negocio/Misión
Proceso de Implantación ISO 33000

Para implantar la norma ISO 33000 es recomendable seguir un
proceso compuesto por 3 fases. Si bien lo importante es la
implantación, este proceso además permitiría obtener como extra
una certificación de conformidad con ISO/IEC 33000, mejorando así
la competitividad de la organización.
Evaluación de la situación inicial respecto a ISO 33000

El primer paso es obtener una visión detallada de la organización
respecto al modelo ISO 33000. Para ello se debe realizar una
evaluación de los procesos del ciclo de vida de desarrollo software
de la organización respecto a los requisitos establecidos en el
modelo ISO 33000.
En esta evaluación inicial se estudiará la documentación sobre los
procesos de la organización y cómo se aplican estos en varios
proyectos de muestra, revisando las evidencias de productos de
trabajo, documentos y artefactos generados durante su realización.
Como resultado de la evaluación inicial se deberá identificar el
"gap" existente entre los procesos de la organización y lo
establecido en el modelo ISO 33000, y se deberán identificar y
definir las acciones de mejora necesarias para solucionar las
carencias detectadas.
Implantación de mejoras en procesos conforme a ISO 33000

El segundo paso consistirá en implantar las mejoras definidas en el
paso anterior. Para ello, se realizarán las adaptaciones necesarias
sobre los procesos del ciclo de vida de desarrollo software, y se
implantarán los procesos ausentes en la organización.
Se deberán considerar las actividades de cada proceso, los roles
que deberán participar, las herramientas y recursos necesarios para
realizarlas, así como los productos y artefactos de entrada y
resultantes de su realización. Se recomienda seguir un enfoque
incremental en esta implantación, comenzando con un proyecto
piloto sobre el que experimentar las mejoras definidas, para
posteriormente institucionalizar estas mejoras como forma general
de trabajar en la organización. Una vez se considere que la
organización ha institucionalizado la forma de trabajar de acuerdo
al modelo ISO 33000 es recomendable realizar una auditoría
interna para afrontar con mayores garantías el proceso de
certificación.
Certificación en ISO 33000

El tercer paso consistirá en pasar el proceso de certificación llevado
a cabo por una entidad certificadora. Este proceso consiste a su vez
de 2 fases de auditoría, en las que se revisa la documentación de la
organización, se realizan entrevistas a personal responsable y
participante en los procesos de la organización y se revisan las
evidencias de los productos y artefactos generados en varios
proyectos de desarrollo llevados a cabo, con el objetivo de
contrastar que los procesos del ciclo de vida de desarrollo software
cumplen con los requisitos establecidos en el modelo ISO 33000.
Si el resultado de la auditoría es positivo, la entidad certificadora
otorgará a la organización el certificado de conformidad con ISO
33000. Posteriormente, como es habitual en la certificación de
normas ISO se deberá participar en auditorías de seguimiento con
periodo anual. En las auditorías de seguimiento la entidad
certificador comprueba que se mantienen los procesos
establecidos. Con un periodo trienal se realiza una auditoría de
renovación, con el fin de renovar la certificación anterior u optar
por algún nivel superior.

Soporte a la implantación ISO 33000
Para la realización de los pasos 1 y 2 las organizaciones pueden
contar con el soporte de empresas expertas en la implantación de
ISO 33000, que sirvan como guía en la evaluación inicial de "gap" y
la definición del plan de mejora, y que proporcionen supervisión y
consejo en la implantación de las mejoras.
Para la obtención del certificado las organizaciones pueden contar
con entidades de certificación como AENOR.
ISO/IEC 25000
ISO/IEC 25000, conocida como SQuaRE (System and Software
Quality Requirements and Evaluation), es una familia de normas
que tiene por objetivo la creación de un marco de trabajo común
para evaluar la calidad del producto software.
La familia ISO/IEC 25000 es el resultado de la evolución de otras
normas anteriores, especialmente de las normas ISO/IEC 9126, que
describe las particularidades de un modelo de calidad del producto
software, e ISO/IEC 14598, que abordaba el proceso de evaluación
de productos software. Esta familia de normas ISO/IEC 25000 se
encuentra compuesta por cinco divisiones.

ISO/IEC 2500n – División de Gestión de Calidad
Las normas que forman este apartado definen todos los modelos,
términos y definiciones comunes referenciados por todas las otras
normas de la familia 25000. Actualmente esta división se encuentra
formada por:
• ISO/IEC 25000 - Guide to SQuaRE: contiene el modelo de la
arquitectura de SQuaRE, la terminología de la familia, un resumen
de las partes, los usuarios previstos y las partes asociadas, así como
los modelos de referencia.
• ISO/IEC 25001 - Planning and Management: establece los
requisitos y orientaciones para gestionar la evaluación y
especificación de los requisitos del producto software.
ISO/IEC 2501n – División de Modelo de Calidad

Las normas de este apartado presentan modelos de calidad
detallados incluyendo características para calidad interna, externa y
en uso del producto software. Actualmente esta división se
encuentra formada por:
• ISO/IEC 25010 - System and software quality models: describe el
modelo de calidad para el producto software y para la calidad en
uso. Esta Norma presenta las características y subcaracterísticas de
calidad frente a las cuales evaluar el producto software.
• ISO/IEC 25012 - Data Quality model: define un modelo general
para la calidad de los datos, aplicable a aquellos datos que se
encuentran almacenados de manera estructurada y forman parte
de un Sistema de Información.

ISO/IEC 2502n – División de Medición de Calidad
Estas normas incluyen un modelo de referencia de la medición de la
calidad del producto, definiciones de medidas de calidad (interna,
externa y en uso) y guías prácticas para su aplicación. Actualmente
esta división se encuentra formada por:
• ISO/IEC 25020 - Measurement reference model and guide:
presenta una explicación introductoria y un modelo de referencia
común a los elementos de medición de la calidad. También
proporciona una guía para que los usuarios seleccionen o
desarrollen y apliquen medidas propuestas por normas ISO.
• ISO/IEC 25021 - Quality measure elements: define y especifica un
conjunto recomendado de métricas base y derivadas que puedan
ser usadas a lo largo de todo el ciclo de vida del desarrollo
software.
• ISO/IEC 25022 - Measurement of quality in use: define
específicamente las métricas para realizar la medición de la calidad
en uso del producto.
• ISO/IEC 25023 - Measurement of system and software product
quality: define específicamente las métricas para realizar la
medición de la calidad de productos y sistemas software.
• ISO/IEC 25024 - Measurement of data quality: define
específicamente las métricas para realizar la medición de la calidad
de datos.
ISO/IEC 2503n – División de Requisitos de Calidad

Las normas que forman este apartado ayudan a especificar
requisitos de calidad que pueden ser utilizados en el proceso de
elicitación de requisitos de calidad del producto software a
desarrollar o como entrada del proceso de evaluación. Para ello,
este apartado se compone de:
•ISO/IEC 25030 - Quality requirements: provee de un conjunto de
recomendaciones para realizar la especificación de los requisitos de
calidad del producto software.
ISO/IEC 2503n – División de Requisitos de Calidad
Las normas que forman este apartado ayudan a especificar
requisitos de calidad que pueden ser utilizados en el proceso de
elicitación de requisitos de calidad del producto software a
desarrollar o como entrada del proceso de evaluación. Para ello,
este apartado se compone de:
• ISO/IEC 25030 - Quality requirements: provee de un conjunto de
recomendaciones para realizar la especificación de los requisitos de
calidad del producto software.
ISO/IEC 2504n – División de Evaluación de Calidad

Este apartado incluye normas que proporcionan requisitos,
recomendaciones y guías para llevar a cabo el proceso de
evaluación del producto software. Esta división se encuentra
formada por:
• ISO/IEC 25040 - Evaluation reference model and guide: propone
un modelo de referencia general para la evaluación, que considera
las entradas al proceso de evaluación, las restricciones y los
recursos necesarios para obtener las correspondientes salidas.
• ISO/IEC 25041 - Evaluation guide for developers, acquirers and
independent evaluators: describe los requisitos y recomendaciones
para la implementación práctica de la evaluación del producto
software desde el punto de vista de los desarrolladores, de los
adquirentes y de los evaluadores independientes.
• ISO/IEC 25042 - Evaluation modules: define lo que la Norma
considera un módulo de evaluación y la documentación, estructura
y contenido que se debe utilizar a la hora de definir uno de estos
módulos.
• ISO/IEC 25045 - Evaluation module for recoverability: define un
módulo para la evaluación de la subcaracterística Recuperabilidad
(Recoverability).

MODELO CMM
El Modelo de Madurez de Capacidades o CMM (Capability Maturity
Model), es un modelo de evaluación de los procesos de una
organización. Fue desarrollado inicialmente para los procesos
relativos al desarrollo e implementación de software por la
Universidad Carnegie-Mellon para el Software Engineering Institute
(SEI).
El SEI es un centro de investigación y desarrollo patrocinado por el
Departamento de Defensa de los Estados Unidos de América y
gestionado por la Universidad Carnegie-Mellon.
Este modelo establece un conjunto de prácticas o procesos clave
agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para
cada área de proceso define un conjunto de buenas prácticas que
habrán de ser:
• Definidas en un procedimiento documentado
• Provistas (la organización) de los medios y formación necesarios
• Ejecutadas de un modo sistemático, universal y uniforme
(institucionalizadas)
• Medidas
• Verificadas
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de
madurez", de modo que una organización que tenga
institucionalizadas todas las prácticas incluidas en un nivel y sus
inferiores, se considera que ha alcanzado ese nivel de madurez.
1 - Inicial. Las organizaciones en este nivel no disponen de un

ambiente estable para el desarrollo y mantenimiento de software.
Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se
ven minados por falta de planificación. El éxito de los proyectos se
basa la mayoría de las veces en el esfuerzo personal, aunque a
menudo se producen fracasos y casi siempre retrasos y
sobrecostes. El resultado de los proyectos es impredecible.

2 - Repetible. En este nivel las organizaciones disponen de unas
prácticas institucionalizadas de gestión de proyectos, existen unas
métricas básicas y un razonable seguimiento de la calidad. La
relación con subcontratistas y clientes está gestionada
sistemáticamente.
3 - Definido. Además de una buena gestión de proyectos, a este

nivel las organizaciones disponen de correctos procedimientos de
coordinación entre grupos, formación del personal, técnicas de
ingeniería más detalladas y un nivel más avanzado de métricas en
los procesos. Se implementan técnicas de revisión por pares (peer
reviews).
4 - Gestionado. Se caracteriza porque las organizaciones disponen

de un conjunto de métricas significativas de calidad y productividad,
que se usan de modo sistemático para la toma de decisiones y la
gestión de riesgos. El software resultante es de alta calidad.
5 - Optimizado. La organización completa está volcada en la mejora

continua de los procesos. Se hace uso intensivo de las métricas y se
gestiona el proceso de innovación.
MODELO CMMI
CMMI (Capability Maturity Model Integration), es un conjunto de
modelos elaborados por el SEI que permiten obtener un
diagnóstico preciso de la madurez de los procesos relacionados con
las tecnologías de la información de una organización, y describe las
tareas que se tienen que llevar a cabo para mejorar esos procesos,
ayudando a las organizaciones a mejorar su capacidad de
desarrollar y de mantener productos y servicios de calidad.

CMMI constituye un marco de referencia de la capacidad de las
organizaciones de desarrollo de software en el desempeño de sus
diferentes procesos, proporcionando una base para la evaluación
de la madurez de las mismas y una guía para implementar una
estrategia para la mejora continua de los mismos.
CMMI recopila las mejores prácticas que dirigen el desarrollo y
mantenimiento de productos y servicios, cubriendo el ciclo de vida
de un producto, desde su concepción hasta su entrega y
mantenimiento.
CMMI es un modelo de procesos, que evalúa la madurez de una
organización basándose en la capacidad de sus procesos y surge
como la integración del CMM (Capability Maturity Model) v.2.0 y de
la ISO 15504 Draft Standar v.1.00.
El propósito de CMMI es evaluar la calidad de los procesos de
software, proporcionando guías para el mejoramiento de los
procesos de la organización y de sus habilidades para gestionar el
desarrollo, adquisición y mantenimiento de productos y servicios.
CMMI al ser un modelo descriptivo, detalla los atributos esenciales
que deberían caracterizar a una organización en un determinado
nivel de madurez. También es un modelo normativo, ya que
contiene prácticas detalladas que caracterizan los tipos normales de
comportamiento esperados en una organización que ejecuta
proyectos a gran escala.
La mejora continua de los procesos se basa en muchos pasos
pequeños y evolutivos en vez de innovaciones revolucionarias.
CMMI proporciona un marco para organizar estos pasos evolutivos
dentro de niveles de maduración que sientan fundamentos
sucesivos para la mejora continua del proceso.
OBJETIVOS DE CMMI
El objetivo principal de CMMI es lograr la madurez en el desarrollo
de software para obtener éxito predecible en los proyectos y de esa
manera evitar el fracaso de los proyectos.

CMMI es una evolución del modelo CMM y al igual que éste busca
evaluar la madurez de los procesos de desarrollo de software en
pos del mejoramiento de los mismos. Al ser un modelo más integral
que CMM, que se aplica únicamente a la Ingeniería de Software,
integra en forma complementaria y opcional otras disciplinas
también asociadas al proceso de negocios como la Ingeniería de
Sistemas, el Desarrollo Integrado de Productos y Procesos y la
Administración de Proveedores de Servicios de Apoyo.
El CMMI está diseñado para ayudar a mejorar el desempeño
proporcionando a las empresas todo lo que necesitan para
desarrollar consistentemente mejores productos y servicios. Pero el
CMMI es más que un modelo de proceso; también es un modelo de
comportamiento. Las empresas pueden utilizar CMMI para abordar
la logística de mejorar el desempeño mediante el desarrollo de
puntos de referencia medibles, pero CMMI también puede ayudar a
crear una estructura para fomentar un comportamiento productivo
y eficiente en toda la organización.
Niveles de madurez CMMI

El modelo CMMI divide la madurez organizacional en cinco niveles.
Para las empresas que adoptan CMMI, el objetivo es elevar la
organización hasta el Nivel 5, el nivel de madurez de “optimización”.
Una vez que las empresas alcanzan este nivel, no terminan con el
CMMI. En cambio, se centran en el mantenimiento y las mejoras
periódicas.
Los niveles de madurez de CMMI son:
Nivel de madurez 0 – Incompleto: en esta etapa, el trabajo “puede

o no completarse”. Los objetivos no se han establecido en este
punto y los procesos solo están formados parcialmente o no
satisfacen las necesidades de la organización.

Nivel de madurez 1: inicial: los procesos se consideran
impredecibles y reactivos. En esta etapa, “el trabajo se completa,
pero a menudo se retrasa y supera el presupuesto”.
Esta es la peor etapa en la que se puede encontrar una empresa: un
entorno impredecible que aumenta el riesgo y la ineficiencia.
Nivel de madurez 2: gestionado: se ha alcanzado un nivel de gestión

de proyectos. Los proyectos se “planifican, ejecutan, miden y
controlan” en este nivel, pero aún quedan muchos problemas por
abordar.
Nivel de madurez 3: definido: en esta etapa, las organizaciones son

más proactivas que reactivas. Existe un conjunto de “estándares
para toda la organización” para “brindar orientación a través de
proyectos, programas y carteras”. Las empresas comprenden sus
deficiencias, cómo abordarlas y cuál es el objetivo de mejora.
Nivel de madurez 4: gestionado cuantitativamente: esta etapa es

más medida y controlada. La organización está trabajando con
datos cuantitativos para determinar procesos predecibles que se
alinean con las necesidades de las partes interesadas. El negocio
está por delante de los riesgos, con más información basada en
datos sobre las deficiencias de los procesos.
Nivel de madurez 5 – Optimización: aquí, los procesos de una

organización son estables y flexibles. En esta etapa final, una
organización estará en constante estado de mejora y respuesta a
cambios u otras oportunidades. La organización es estable, lo que
permite más “agilidad e innovación” en un entorno predecible.
Una vez que las organizaciones alcanzan los Niveles 4 y 5, se las
considera de alta madurez, donde están “evolucionando,
adaptándose y creciendo continuamente para satisfacer las
necesidades de las partes interesadas y los clientes”.
Ese es el objetivo del CMMI: Crear entornos confiables, donde los
productos, servicios y departamentos sean proactivos, eficientes y
productivos.
Niveles de capacidad CMMI

El CMMI también tiene niveles de capacidad que se utilizan para
evaluar el desempeño de una organización y la mejora del proceso
según se aplica a un área de práctica individual descrita en el
modelo CMMI. Puede ayudar a estructurar el proceso y mejorar el
desempeño y cada nivel se basa en el anterior, similar a los niveles
de madurez para evaluar una organización.
Los niveles de capacidad son:
Nivel de capacidad 0 – Incompleto: desempeño inconsistente y un

“enfoque incompleto para cumplir con la intención del área de
práctica”.
Nivel de capacidad 1: Inicial: la fase en la que las organizaciones

comienzan a abordar los problemas de desempeño en un área de
práctica específica, pero no existe un conjunto completo de
prácticas.
Nivel de capacidad 2: Administrado: el progreso está comenzando

a mostrarse y existe un conjunto completo de prácticas que
abordan específicamente la mejora en el área de práctica.
Nivel de capacidad 3 – Definido: Hay un enfoque en el logro de los

objetivos de desempeño organizacional y del proyecto y existen
estándares organizacionales claros para abordar proyectos en esa
área de práctica.

CALIDAD DEL
SOFTWARE
TEMA: Aseguramiento
de la Calidad

El aseguramiento de la calidad del software (con frecuencia llamado
administración de la calidad) es una actividad sombrilla que se
aplica en todo el proceso del software.
El aseguramiento de la calidad del software (SQA o ACS) incluye lo
siguiente:
1) Un proceso de ACS.
2) Tareas específicas de aseguramiento y control de la calidad
(incluidas revisiones técnicas y una estrategia de pruebas
relacionadas entre sí).
3) Prácticas eficaces de ingeniería de software (métodos y
herramientas).
4) Control de todos los productos del trabajo de software y de los
cambios que sufren.
5) Un procedimiento para garantizar el cumplimiento de los
estándares del desarrollo de software (cuando sea aplicable).
6) Mecanismos de medición y reporte.
Lo importante es centrarse en aspectos de la administración y en

las actividades específicas del proceso que permiten a una
organización de software garantizar que hace “las cosas correctas
en el momento correcto y de la forma correcta”.

El control y aseguramiento de la calidad son actividades esenciales
para cualquier negocio que genere productos que utilicen otras
personas. Antes del siglo XX, el control de calidad era
responsabilidad única del artesano que elaboraba el producto.
Cuando pasó el tiempo y las técnicas de la producción en masa se
hicieron comunes, el control de calidad se convirtió en una
actividad ejecutada por personas diferentes de aquellas que
elaboraban el producto.
La primera función formal de aseguramiento y control de la calidad
se introdujo en los laboratorios Bell en 1916 y se difundió con
rapidez al resto del mundo de la manufactura.
Durante la década de 1940, sugirieron enfoques más formales del
control de calidad. Éstos se basaban en la medición y en el proceso
de la mejora continua como elementos clave de la administración
de la calidad.
Actualmente, toda compañía tiene mecanismos para asegurar la
calidad en sus productos.
La historia del aseguramiento de la calidad en el desarrollo del
software corre de manera paralela con la historia de la calidad en la
manufactura del hardware. En los primeros días de la computación
(décadas de 1950 y 1960), la calidad era responsabilidad única del
programador.
Los estándares para asegurar la calidad del software se introdujeron
en los contratos para desarrollar software militar en la década de
1970 y se extendieron con rapidez al desarrollo de software en el
mundo comercial. Si se amplía la definición presentada al principio,
el aseguramiento de la calidad del software es un “patrón planeado
y sistemático de acciones” que se requieren para garantizar alta
calidad en el software.

El alcance de la responsabilidad del aseguramiento de la calidad se
caracteriza mejor si se parafrasea un comercial de un automóvil
popular: “La calidad es el empleo N° 1”. La implicación para el
software es que varias entidades diferentes tienen responsabilidad
en el aseguramiento de la calidad del software: ingenieros de
software, gerentes de proyecto, clientes, vendedores y los
individuos que trabajan en el grupo de ACS.
El grupo de ACS funciona como representante del cliente en el
interior de la empresa. Es decir, la gente que realiza el ACS debe ver
al software desde el punto de vista del cliente.
¿El software cumple adecuadamente los factores de calidad? ¿El
desarrollo del software se condujo de acuerdo con estándares
preestablecidos? ¿Las disciplinas técnicas han cumplido con sus
roles como parte de la actividad de ACS?
El grupo de ACS trata de responder éstas y otras preguntas para
garantizar que se mantenga la calidad del software.

El aseguramiento de la calidad del software incluye un rango amplio
de preocupaciones y actividades que se centran en la
administración de la calidad del software. Éstas se resumen como
sigue:
Estándares. El IEEE, ISO y otras organizaciones que establecen
estándares han producido una amplia variedad de ellos para la
ingeniería de software y documentos relacionados.
Los estándares los adopta, de manera voluntaria, una organización
de software o los impone el cliente u otros participantes. El trabajo
del ACS es asegurar que los estándares que se hayan adoptado se
sigan, y que todos los productos del trabajo se apeguen a ellos.
Revisiones y auditorías. Las revisiones técnicas son una actividad
del control de calidad que realizan ingenieros de software para
otros ingenieros de software. Su objetivo es detectar errores. Las
auditorías son un tipo de revisión efectuada por personal de ACS
con objeto de garantizar que se sigan los lineamientos de calidad en
el trabajo de la ingeniería de software. Por ejemplo, una auditoría
del proceso de revisión se efectúa para asegurar que las revisiones
se lleven a cabo de manera que tengan la máxima probabilidad de
descubrir errores.
Pruebas. Las pruebas del software son una función del control de
calidad que tiene un objetivo principal: detectar errores. El trabajo
del ACS es garantizar que las pruebas se planeen en forma
apropiada y que se realicen con eficiencia, de modo que la
probabilidad de que logren su objetivo principal sea máxima.
Colección y análisis de los errores. La única manera de mejorar es
medir cómo se está haciendo algo. El ACS reúne y analiza errores y
datos acerca de los defectos para entender mejor cómo se cometen
los errores y qué actividades de la ingeniería de software son más
apropiadas para eliminarlos.

Administración del cambio. El cambio es uno de los aspectos que
más irrumpe en cualquier proyecto de software. Si no se administra
en forma adecuada, lleva a la confusión y ésta casi siempre genera
mala calidad. El ACS asegura que se hayan instituido prácticas
adecuadas de administración del cambio.
Educación. Toda organización de software quiere mejorar sus
prácticas de ingeniería de software. Un contribuyente clave de la
mejora es la educación de los ingenieros de software, de sus
gerentes y de otros participantes. La organización de ACS lleva el
liderazgo en la mejora del proceso de software y es clave para
proponer y patrocinar programas educativos.
Administración de los proveedores. Son tres las categorías de
software que se adquieren a proveedores externos: paquetes
contenidos en una caja (por ejemplo, Office de Microsoft); un shell
personalizado, que da una estructura básica, tipo esqueleto, que se
adapta de manera única a las necesidades del comprador; y
software contratado, que se diseña y construye especialmente a
partir de especificaciones provistas por la organización cliente. El
trabajo de la organización de ACS es garantizar que se obtenga
software de alta calidad a partir de las sugerencias de prácticas
específicas de calidad que el proveedor debe seguir (cuando sea
posible) y de la incorporación de cláusulas de calidad como parte de
cualquier contrato con un proveedor externo.
Administración de la seguridad. Con el aumento de los delitos
cibernéticos y de las nuevas regulaciones gubernamentales
respecto de la privacidad, toda organización de software debe
instituir políticas para proteger los datos en todos los niveles,
establecer cortafuegos de protección para las webapps y asegurar
que el software no va a ser vulnerado internamente. El ACS
garantiza que para lograr la seguridad del software, se utilicen el
proceso y la tecnología apropiados.

Seguridad. Debido a que el software casi siempre es un
componente crucial de los sistemas humanos (como aplicaciones
automotrices o aeronáuticas), la consecuencia de defectos ocultos
puede ser catastrófica. El ACS es responsable de evaluar el efecto
de las fallas del software y de dar los pasos que se requieren para
disminuir el riesgo.
Administración de riesgos. Aunque el análisis y la mitigación de
riesgos es asunto de los ingenieros de software, la organización del
ACS garantiza que las actividades de administración de riesgos se
efectúen en forma apropiada y que se establezcan planes de
contingencia relacionados con los riesgos.
Además de cada una de estas preocupaciones y actividades, el ACS

tiene como preocupación dominante asegurar que las actividades
de apoyo del software (como mantenimiento, líneas de ayuda,
documentación y manuales) se lleven a cabo o se produzcan con
calidad.

El aseguramiento de la calidad del software se compone de varias
tareas asociadas con dos entidades diferentes: los ingenieros de
software que hacen el trabajo técnico y un grupo de ACS que tiene
la responsabilidad de planear, supervisar, registrar, analizar y hacer
reportes acerca de la calidad.
Los ingenieros de software abordan la calidad (y ejecutan
actividades para controlarla), aplicando métodos y medidas
técnicas sólidos, realizando revisiones técnicas y haciendo pruebas
de software bien planeadas.
Tareas del ACS
El objetivo del grupo de ACS es auxiliar al equipo del software para
lograr un producto final de alta calidad. El Instituto de Ingeniería de
Software recomienda un conjunto de acciones de ACS que se
dirigen a la planeación, supervisión, registro, análisis y elaboración
de reportes para el aseguramiento de la calidad. Estas acciones son
realizadas (o facilitadas) por un grupo independiente de ACS que
hace lo siguiente:
Prepara el plan de ACS para un proyecto. El plan se desarrolla
como parte de la preparación del proyecto y es revisado por todos
los participantes. Las acciones de aseguramiento de la calidad
efectuadas por el equipo de ingeniería de software y por el grupo
de ACS son dirigidas por el plan. Éste identifica las evaluaciones que
se van a realizar, las auditorías y revisiones por efectuar, los
estándares aplicables al proyecto, los procedimientos para reportar
y dar seguimiento a los errores, los productos del trabajo que
genera el grupo de ACS y la retroalimentación que se dará al equipo
del software.

Participa en el desarrollo de la descripción del software del
proyecto. El equipo de software selecciona un proceso para el
trabajo que se va a realizar. El grupo de ACS revisa la descripción del
proceso a fin de cumplir con la política organizacional, los
estándares internos para el software, los estándares impuestos
desde el exterior (como la norma ISO-9001) y otras partes del plan
del proyecto de software.
Revisa las actividades de la ingeniería de software a fin de
verificar el cumplimiento mediante el proceso definido para el
software. El grupo de ACS identifica, documenta y da seguimiento a
las desviaciones del proceso y verifica que se hayan hecho las
correcciones pertinentes.
Audita los productos del trabajo de software designados para
verificar que se cumpla con aquellos definidos como parte del
proceso de software. El grupo de ACS revisa productos del trabajo
seleccionados; identifica, documenta y da seguimiento a las
desviaciones; verifica que se hayan hecho las correcciones
necesarias y reporta periódicamente los resultados de su trabajo al
gerente del proyecto.
Asegura que las desviaciones en el trabajo de software y sus
productos se documenten y manejen de acuerdo con un
procedimiento documentado. Las desviaciones pueden
encontrarse en el plan del proyecto, la descripción del proceso, los
estándares aplicables o los productos del trabajo de la ingeniería de
software.
Registra toda falta de cumplimiento y la reporta a la alta dirección.
Se da seguimiento a los incumplimientos hasta que son resueltos.
Además de estas acciones, el grupo de ACS coordina el control y

administración del cambio y ayuda a recabar y analizar métricas
para el software.

Las acciones de ACS descritas en la sección anterior se realizan con
objeto de alcanzar un conjunto de metas pragmáticas:
Calidad de los requerimientos. La corrección, completitud y
consistencia del modelo de requerimientos tendrá una gran
influencia en la calidad de todos los productos del trabajo que
sigan. El ACS debe garantizar que el equipo de software ha revisado
en forma apropiada el modelo de requerimientos a fin de alcanzar
un alto nivel de calidad.
Calidad del diseño. Todo elemento del modelo del diseño debe ser
evaluado por el equipo del software para asegurar que tenga alta
calidad y que el diseño en sí se apegue a los requerimientos. El ACS
busca atributos del diseño que sean indicadores de la calidad.
Calidad del código. El código fuente y los productos del trabajo
relacionados (por ejemplo, otra información descriptiva) deben
apegarse a los estándares locales de codificación y tener
características que faciliten darle mantenimiento. El ACS debe
identificar aquellos atributos que permitan hacer un análisis
razonable de la calidad del código.
Eficacia del control de calidad. Un equipo de software debe aplicar
recursos limitados, en forma tal que tenga la máxima probabilidad
de lograr un resultado de alta calidad. El ACS analiza la asignación
de recursos para las revisiones y pruebas a fin de evaluar si se
asignan en la forma más eficaz.

En las secciones anteriores, se dijo que la calidad del software es el
trabajo de cada quien y que puede lograrse por medio de una
práctica competente de la ingeniería de software, así como de la
aplicación de revisiones técnicas, de una estrategia de pruebas con
relaciones múltiples, de un mejor control de los productos del
trabajo de software y de los cambios efectuados sobre ellos, así
como de la aplicación de estándares aceptados de la ingeniería de
software. Además, la calidad se define en términos de una amplia
variedad de atributos de la calidad y se mide (indirectamente) con
el empleo de varios índices y métricas.
En las últimas tres décadas, un segmento pequeño pero sonoro de
la comunidad de la ingeniería de software ha afirmado que se
requiere un enfoque más formal para el ACS. Puede decirse que un
programa de cómputo es un objeto matemático. Para cada lenguaje
de programación, es posible definir una sintaxis y semántica
rigurosas, y se dispone de un enfoque igualmente riguroso para la
especificación de los requerimientos del software. Si el modelo de
los requerimientos (especificación) y el lenguaje de programación
se representan en forma rigurosa, debe ser posible usar una
demostración matemática para la corrección, de modo que se
confirme que un programa se ajusta exactamente a sus
especificaciones.
Los intentos de demostrar la corrección de un programa no son
nuevos. Dijkstra y Linger, Mills y Witt, entre otros, han invocado
pruebas de la corrección de programas y las han relacionado con el
uso de conceptos de programación estructurada.

ASEGURAMIENTO ESTADÍSTICO DE LA CALIDAD DEL SOFTWARE
El aseguramiento estadístico de la calidad del software refleja una
tendencia creciente en la industria para que se vuelva más
cuantitativo respecto de la calidad.
Para el software, el aseguramiento estadístico de la calidad implica
los pasos siguientes:
1. Se recaba y clasifica la información acerca de errores y defectos
del software.
2. Se hace un intento por rastrear cada error y defecto hasta sus
primeras causas (por ejemplo, no conformidad con las
especificaciones, error de diseño, violación de los estándares, mala
comunicación con el cliente, etc.).
3. Con el uso del Principio de Pareto (80 por ciento de los defectos
se debe a 20 por ciento de todas las causas posibles), se identifica
20 por ciento de las causas de errores y defectos (las pocas vitales).
4. Una vez identificadas las pocas causas vitales, se corrigen los
problemas que han dado origen a los errores y defectos.
Este concepto relativamente simple representa un paso importante

hacia la creación de un proceso adaptativo del software en el que
se hacen cambios para mejorar aquellos elementos del proceso que
introducen errores.

No hay duda de que la confiabilidad de un programa de cómputo es
un elemento importante de su calidad general. Si un programa falla
repetida y frecuentemente en su desempeño, importa poco si otros
factores de la calidad del software son aceptables.
La confiabilidad del software, a diferencia de muchos otros factores
de la calidad, se mide y estima directamente mediante el uso de
datos históricos del desarrollo. La confiabilidad del software se
define en términos estadísticos como “la probabilidad que tiene un
programa de cómputo de operar sin fallas en un ambiente
específico por un tiempo específico”. Para ilustrar lo anterior,
digamos que se estima que el programa X tiene una confiabilidad
de 0.999 durante ocho horas de procesamiento continuo. En otras
palabras, si el programa X fuera a ejecutarse 1000 veces y requiera
un total de ocho horas de tiempo de procesamiento continuo
(tiempo de procesamiento), es probable que operara
correctamente (sin fallas) 999 veces.
Siempre que se trate de la confiabilidad del software, surge una
pregunta crucial: ¿qué significa el término falla? En el contexto de
cualquier análisis de la calidad y confiabilidad del software, la falla
significa la falta de conformidad con los requerimientos del
software. Pero, incluso con esta definición, hay gradaciones. Las
fallas pueden ser leves o catastróficas. Una falla podría corregirse
en segundos, mientras que otra tal vez requiera de varias semanas
o meses de trabajo para ser corregida. Para complicar más el
asunto, la corrección de una falla quizá dé como resultado la
introducción de otros errores que a su vez originen otras fallas.
Mediciones de la confiabilidad y disponibilidad
Los primeros trabajos sobre confiabilidad del software trataban de
extrapolar la teoría matemática de la confiabilidad del hardware a
la predicción de la confiabilidad del software. La mayor parte de
modelos relacionados con el hardware se abocan a la falla debida al
uso, en lugar de a la que tiene su origen en los defectos de diseño.

En el hardware, las fallas debidas al uso físico (por ejemplo, los
efectos de temperatura, corrosión y golpes) son más probables que
las debidas al diseño. Desafortunadamente, con el software ocurre
lo contrario. En realidad, todas las fallas del software pueden
rastrearse en problemas de diseño o de implementación; el uso no
entra en el escenario.
Ha habido un debate permanente acerca de la relación que existe
entre los conceptos clave en la confiabilidad del hardware y su
aplicabilidad al software. Aunque es posible establecer un vínculo
irrefutable, es útil considerar algunos conceptos sencillos que se
aplican a ambos elementos del sistema.
Si se considera un sistema basado en computadora, una medida
sencilla de su confiabilidad es el tiempo medio entre fallas (TMEF):
TMEF = TMPF + TMPR
donde las siglas TMPF y TMPR significan tiempo medio para la falla
tiempo medio para la reparación, respectivamente.
Muchos investigadores afirman que el TMEF es una medición más

útil que otras relacionadas con la calidad del software. En pocas
palabras, a un usuario final le preocupan las fallas, no la cuenta
total de defectos. Como cada defecto contenido en un programa no
tiene la misma tasa de fallas, la cuenta total de defectos indica muy
poco acerca de la confiabilidad del sistema. Por ejemplo, considere
un programa que haya estado en operación durante 3000 horas de
procesador sin falla. Muchos defectos de este programa estarían sin
detectar durante decenas de miles de horas antes de ser
descubiertos.

El TMEF de tales errores oscuros podría ser de 30000 o hasta 60000
horas de procesador. Otros defectos, no descubiertos, podrían
tener una tasa de fallas de 4000 a 5000 horas. Aun si cada uno de
los errores en esta categoría (los que tienen un TMEF largo) se
eliminara, el efecto que tendrían sobre el software sería
despreciable.
Sin embargo, el TMEF puede ser problemático por dos razones: 1)
proyecta un tiempo entre fallas, pero no da una tasa de fallas
proyectada y 2) puede interpretarse mal, como la vida promedio,
cuando no es esto lo que implica.
Una medición alternativa de confiabilidad es la de las fallas en el
tiempo (FET): medición estadística de cuántas fallas tendrá un
componente en mil millones de horas de operación. Por tanto, 1
FET es equivalente a una falla en cada mil millones de horas de
operación.
Además de una medida de la confiabilidad, también debe
desarrollarse otra para la disponibilidad.
La disponibilidad del software es la probabilidad de que un
programa opere de acuerdo con los requerimientos en un
momento determinado de tiempo, y se define así:
La medición del TMEF para la confiabilidad es igualmente sensible

al TMPF y al TMPR. La medición de la disponibilidad es un poco más
sensible al TMPR, que es una medición indirecta de la facilidad que
tiene el software para recibir mantenimiento.
PUNTOS CLAVE
Los problemas de confiabilidad del software casi siempre pueden seguirse
hasta encontrar defectos en el diseño o en la implementación.
Es importante observar que el tiempo medio entre fallas y otras medidas
relacionadas se basa en tiempo del CPU, no en tiempo de reloj.

Seguridad del software
La seguridad del software es una actividad del aseguramiento del
software que se centra en la identificación y evaluación de los
peligros potenciales que podrían afectarlo negativamente y que
podrían ocasionar que falle todo el sistema. Si los peligros se
identifican al principio del proceso del software, las características
de su diseño se especifican de modo que los eliminen o controlen.
Como parte de la seguridad del software, se lleva a cabo un proceso
de modelado y análisis.
Inicialmente se identifican los peligros y se clasifican según su
riesgo. Por ejemplo, algunos de los peligros asociados con un
control de crucero basado en computadora para un automóvil
podrían ser los siguientes: 1) ocasionar una aceleración
incontrolada que no pudiera detenerse, 2) no responder a la
presión en el pedal de frenado (porque se apaga), 3) no encender
cuando se active el interruptor y 4) perder o ganar velocidad poco a
poco. Una vez identificados estos peligros en el nivel del sistema, se
utilizan técnicas de análisis para asignar severidad y probabilidad de
ocurrencia a cada uno. Para ser eficaz, el software debe analizarse
en el contexto de todo el sistema. Por ejemplo, un error sutil en la
entrada de un usuario (las personas son componentes del sistema)
podría ampliarse por una falla del software y producir datos de
control que situaran equivocadamente un dispositivo mecánico. Si y
sólo si se encontrara un único conjunto de condiciones ambientales
externas, la posición falsa del dispositivo mecánico ocasionaría una
falla desastrosa. Podrían usarse técnicas de análisis, tales como
árbol de fallas, lógica en tiempo real y modelos de red de Petri, para
predecir la cadena de eventos que ocasionarían los peligros, así
como la probabilidad de ocurrir que tendría cada uno de los
eventos para generar la cadena.

Una vez identificados y analizados los peligros, pueden especificarse
requerimientos relacionados con la seguridad para el software. Es
decir, la especificación contendría una lista de eventos indeseables
y las respuestas deseadas del sistema ante ellos. Después se
indicaría el papel del software en la administración indeseable de
los mismos.
Aunque la confiabilidad y la seguridad del software están muy
relacionadas, es importante entender la sutil diferencia entre ellas.
La primera utiliza técnicas de análisis estadístico para determinar la
probabilidad de que ocurra una falla del software. Sin embargo, la
ocurrencia de una falla no necesariamente da como resultado un
peligro o riesgo. La seguridad del software examina las formas en
las que las fallas generan condiciones que llevan a un peligro. Es
decir, las fallas no se consideran en el vacío, sino que se evalúan en
el contexto de la totalidad del sistema basado en computadora y de
su ambiente.

LAS NORMAS DE CALIDAD ISO 9000
Un sistema de aseguramiento de la calidad se define como la
estructura organizacional, responsabilidades, procedimientos,
procesos y recursos necesarios para implementar la administración
de la calidad. Los sistemas de aseguramiento de la calidad se crean
para ayudar a las organizaciones a asegurar que sus productos y
servicios satisfagan las expectativas del consumidor gracias a que
cumplan con sus especificaciones. Estos sistemas cubren una
amplia variedad de actividades, que contemplan todo el ciclo de
vida del producto, incluidos planeación, control, medición, pruebas
e informes, así como la mejora de los niveles de calidad en todo el
proceso de desarrollo y manufactura. La norma ISO 9000 describe
en términos generales los elementos de aseguramiento de la
calidad que se aplican a cualquier negocio, sin importar los
productos o servicios ofrecidos.
Para registrarse en alguno de los modelos del sistema de
aseguramiento de la calidad contenidos en la ISO 9000, por medio
de auditores externos se revisan en detalle el sistema y las
operaciones de calidad de una compañía, respecto del
cumplimiento del estándar y de la operación eficaz. Después de un
registro exitoso, el grupo de registro representado por los auditores
emite un certificado para la compañía. Auditorías semestrales de
supervisión aseguran el cumplimiento continuo de la norma.
Los requerimientos esbozados por la norma ISO 9001:2000 se
dirigen a temas tales como responsabilidad de la administración,
sistema de calidad, revisión del contrato, control del diseño,
documentación y control de datos, identificación del producto y su
seguimiento, control del proceso, inspección y pruebas, acciones
correctivas y preventivas, registros del control de calidad, auditorías
internas de calidad, capacitación, servicio y técnicas estadísticas.

A fin de que una organización de software se registre en la ISO
9001:2000, debe establecer políticas y procedimientos que
cumplan cada uno de los requerimientos mencionados (y otros
más), y después demostrar que sigue dichas políticas y
procedimientos.

El Plan de ACS proporciona un mapa de ruta para instituir el
aseguramiento de la calidad del software. Desarrollado por el grupo
de ACS (o por el equipo del software si no existe un grupo de ACS),
el plan funciona como plantilla para las actividades de ACS que se
instituyen para cada proyecto de software.
La IEEE ha publicado una norma para el ACS. Ésta recomienda una
estructura que identifica lo siguiente:
1) Propósito y alcance del plan.

2) Descripción de todos los productos del trabajo de ingeniería de
software (tales como modelos, documentos, código fuente,
etc.) que se ubiquen dentro del ámbito del ACS.
3) Todas las normas y prácticas aplicables que se utilicen durante
el proceso del software.
4) Acciones y tareas del ACS (incluidas revisiones y auditorías) y su
ubicación en el proceso del software.
5) Herramientas y métodos que den apoyo a las acciones y tareas
de ACS.
6) Procedimientos para la administración de la configuración del
software.
7) Métodos para unificar las salvaguardas y para mantener todos
los registros relacionados con el ACS.
8) Roles y responsabilidades relacionados con la calidad del
producto.

El aseguramiento de la calidad del software es una actividad
sombrilla de la ingeniería de software que se aplica en cada etapa
del proceso del software. El ACS incluye procedimientos para la
aplicación eficaz de métodos y herramientas, supervisa las
actividades de control de calidad, tales como las revisiones técnicas
y las pruebas del software, procedimientos para la administración
del cambio, y procedimientos para asegurar el cumplimiento de las
normas y mecanismos de medición y elaboración de reportes.
Para llevar a cabo el aseguramiento de la calidad del software de
manera adecuada, deben recabarse, evaluarse y divulgarse datos
sobre el proceso de la ingeniería de software. Los métodos
estadísticos aplicados al ACS ayudan a mejorar la calidad del
producto y del proceso de software mismo. Los modelos de
confiabilidad del software amplían las mediciones, lo que permite
que los datos obtenidos acerca de los defectos se extrapolen hacia
tasas de falla proyectadas y hacia la elaboración de pronósticos de
confiabilidad.
En resumen, deben tomarse en cuenta las palabras de Dunn y
Ullman: “El aseguramiento de la calidad del software es el mapeo
de los preceptos administrativos y de las disciplinas de diseño del
aseguramiento de la calidad, en el ámbito administrativo y
tecnológico aplicable a la ingeniería de software”. La capacidad de
asegurar la calidad es la medida de una disciplina madura de la
ingeniería. Cuando el mapeo se lleva a cabo con éxito, el resultado
es una ingeniería de software madura.

DIEZ HEURÍSTICAS DE USABILIDAD PARA EL DISEÑO DE INTERFACES DE USUARIO.
Resumen: Los 10 principios generales de Jakob Nielsen para el diseño de interacción. Se

denominan "heurísticas" porque son reglas generales y no pautas de usabilidad específicas.
#1: Visibilidad del estado del sistema

El diseño siempre debe mantener a los usuarios informados sobre lo que está sucediendo, a
través de comentarios adecuados dentro de un período de tiempo razonable.
Cuando los usuarios conocen el estado actual del sistema, conocen el resultado de sus
interacciones anteriores y determinan los próximos pasos. Las interacciones predecibles crean
confianza tanto en el producto como en la marca.
Ejemplo de heurística de usabilidad n.° 1:

Los indicadores Estás aquí en los mapas de los centros comerciales muestran a las personas
dónde se encuentran actualmente, para ayudarte a comprender adónde ir a continuación.
Consejos
• Comunique claramente a los usuarios cuál es el estado del sistema; no se debe realizar
ninguna acción con consecuencias para los usuarios sin informarles.
• Presente comentarios al usuario lo más rápido posible (idealmente, inmediatamente).
• Generar confianza a través de una comunicación abierta y continua .
#2: Coincidencia entre el sistema y el mundo real

El diseño debe hablar el idioma de los usuarios. Utilice palabras, frases y conceptos familiares
para el usuario, en lugar de jerga interna. Siga las convenciones del mundo real, haciendo que la
información aparezca en un orden natural y lógico.
La forma en que debes diseñar depende en gran medida de tus usuarios específicos. Los
términos, conceptos, íconos e imágenes que a usted ya sus colegas les parecen perfectamente
claros pueden resultar desconocidos o confusos para sus usuarios.
Cuando los controles de un diseño siguen las convenciones del mundo real y corresponden a los
resultados deseados (llamado mapeo natural ), es más fácil para los usuarios aprender y
recordar cómo funciona la interfaz. Esto ayuda a crear una experiencia que se sienta intuitiva.
cuando los controles de la estufa coinciden con el diseño de los elementos calefactores, los
usuarios pueden comprender rápidamente qué control se asigna a qué elemento calefactor.
Consejos
• Asegúrese de que los usuarios puedan comprender el significado sin tener que buscar la
definición de una palabra.
• Nunca asuma que su comprensión de palabras o conceptos coincidirá con la de sus
usuarios.
• La investigación de usuarios descubrirá la terminología familiar de sus usuarios, así como
sus modelos mentales en torno a conceptos importantes.
#3: control y libertad del usuario

Los usuarios suelen realizar acciones por error. Necesitan una "salida de emergencia"
claramente marcada para abandonar la acción no deseada sin tener que pasar por un proceso
prolongado.
Cuando a las personas les resulta fácil retirarse de un proceso o deshacer una acción, se fomenta
una sensación de libertad y confianza. Las salidas permiten a los usuarios mantener el control
del sistema y evitar quedarse atascados y sentirse frustrados.
Los espacios digitales necesitan salidas de emergencia rápidas, al igual que los espacios físicos.
Consejos
• Admitir Deshacer y Rehacer.
• Muestra una forma clara de salir de la interacción actual, como un botón Cancelar.
• Asegúrese de que la salida esté claramente etiquetada y sea visible.
#4: Coherencia y estándares

Los usuarios no deben tener que preguntarse si diferentes palabras, situaciones o acciones
significan lo mismo. Siga las convenciones de la industria y la plataforma.
La Ley de Jakob establece que las personas pasan la mayor parte de su tiempo utilizando
productos digitales distintos al suyo. Las experiencias de los usuarios con esos otros productos
establecen sus expectativas. No mantener la coherencia puede aumentar la carga cognitiva de
los usuarios al obligarlos a aprender algo nuevo.
Los mostradores de facturación suelen estar ubicados en la parte delantera de los hoteles. Esta
consistencia cumple con las expectativas de los clientes.
Consejos
• Mejore la capacidad de aprendizaje manteniendo ambos tipos de coherencia: interna y
externa.
• Mantener la coherencia dentro de un solo producto o una familia de productos
(consistencia interna).
• Seguir las convenciones establecidas de la industria (consistencia externa).
#5: Prevención de errores

Los buenos mensajes de error son importantes, pero los mejores diseños evitan cuidadosamente
que ocurran problemas en primer lugar. Elimine las condiciones propensas a errores o
verifíquelas y presente a los usuarios una opción de confirmación antes de comprometerse con
la acción.
Hay dos tipos de errores: deslices y equivocaciones. Los resbalones son errores inconscientes
causados por falta de atención. Los errores son errores conscientes basados en un desajuste
entre el modelo mental del usuario y el diseño.

Las barandillas en carreteras de montaña con curvas evitan que los conductores se caigan de los
acantilados.
Consejos
• Priorice su esfuerzo: evite primero los errores de alto costo y luego las pequeñas
frustraciones.
• Evite errores al proporcionar restricciones útiles y buenos valores predeterminados.
• Evite errores eliminando cargas de memoria, admitiendo deshacer y advirtiendo a sus
usuarios.
#6: Reconocimiento en lugar de recuerdo

Minimiza la carga de memoria del usuario haciendo elementos visibles, acciones y opciones. El
usuario no debería tener que recordar información de una parte de la interfaz a otra. La
información requerida para utilizar el diseño (por ejemplo, etiquetas de campo o elementos de
menú) debe ser visible o fácilmente recuperable cuando sea necesario.
Los humanos tenemos memorias limitadas a corto plazo. Las interfaces que promueven el
reconocimiento reducen la cantidad de esfuerzo cognitivo requerido por parte de los usuarios.
Para la mayoría de las personas es más fácil reconocer las capitales de los países, en lugar de
tener que recordarlas. Es más probable que las personas respondan correctamente a la pregunta
¿Es Lisboa la capital de Portugal? en lugar de ¿Cuál es la capital de Portugal?.
Consejos
• Permita que las personas reconozcan la información en la interfaz, en lugar de obligarlas
a recordarla (“recordarla”).
• Ofrezca ayuda en contexto, en lugar de ofrecer a los usuarios un largo tutorial para
memorizar.
• Reducir la información que los usuarios tienen que recordar.
#7: Flexibilidad y eficiencia de uso

Los atajos, ocultos para los usuarios novatos, pueden acelerar la interacción del usuario experto,
de modo que el diseño pueda atender tanto a usuarios experimentados como a
inexpertos. Permitir a los usuarios personalizar las acciones frecuentes.
Los procesos flexibles se pueden llevar a cabo a cabo de diferentes maneras, de modo que las
personas puedan elegir el método que más les convenga.
Ejemplo de heurística de usabilidad n.º 7:

Las rutas habituales se enumeran en los mapas, pero los locales con conocimiento de la zona
pueden tomar atajos.
Consejos
• Proporcione aceleradores como atajos de teclado y gestos táctiles.
• Proporciona personalización adaptando el contenido y la funcionalidad a usuarios
individuales.
• Permitir la personalización , para que los usuarios puedan seleccionar cómo quieren que
funcione el producto.
#8: Diseño estético y minimalista

Las interfaces no deben contener información que sea irrelevante o que rara vez se
necesite. Cada unidad adicional de información en una interfaz compite con las unidades de
información relevantes y disminuye su visibilidad relativa.
Esta heurística no significa que tengas que usar un diseño plano; se trata de asegurarte de
mantener el contenido y el diseño visual enfocados en lo esencial. Asegúrese de que los
elementos visuales de la interfaz respalden los objetivos principales del usuario.

Una tetera ornamentada puede tener elementos decorativos excesivos, como un mango
incómodo o una boquilla difícil de lavar, que pueden interferir con la usabilidad.
Consejos
• Mantenga el contenido y el diseño visual de la interfaz de usuario centrados en lo
esencial.
• No permita que elementos innecesarios distraigan a los usuarios de la información que
realmente necesitan.
• Priorice el contenido y las funciones para respaldar los objetivos principales.
#9: Ayude a los usuarios a reconocer, diagnosticar y recuperarse de errores

Los mensajes de error deben expresarse en un lenguaje sencillo (sin códigos de error), indicar
con precisión el problema y sugerir una solución de manera constructiva.
Estos mensajes de error también deben presentarse con tratamientos visuales que ayuden a los
usuarios a notarlos y reconocerlos.
Las señales de sentido contrario en la carretera recuerdan a los conductores que van en la
dirección equivocada y les piden que se detengan.
Consejos
• Utilice elementos visuales tradicionales para mensajes de error, como texto en negrita y
rojo.
• Informe a los usuarios qué salió mal en un lenguaje que puedan entender. Evite la jerga
técnica.
• Ofrezca a los usuarios una solución, como un acceso directo que pueda resolver el error
de inmediato.
#10: Ayuda y documentación

Es mejor si el sistema no necesita ninguna explicación adicional. Sin embargo, puede ser
necesario proporcionar documentación para ayudar a los usuarios a comprender cómo
completar sus tareas.
El contenido de ayuda y documentación debe ser fácil de buscar y estar centrado en la tarea del
usuario. Sea conciso y enumera los pasos concretos que deben llevarse a cabo.

Los quioscos de información en los aeropuertos son fácilmente reconocibles y resuelven los
problemas de los clientes en contexto e inmediatamente.
Consejos
• Asegúrese de que la documentación de ayuda sea fácil de buscar.
• Siempre que sea posible, presente la documentación en contexto justo en el momento
que el usuario lo requiera.
• Enumerar los pasos concretos a llevar a cabo.
TESTING
TEMA: Introducción

Una estrategia de prueba de software proporciona una guía que
describe los pasos que deben realizarse como parte de la prueba,
cuándo se planean y se llevan a cabo dichos pasos, y cuánto
esfuerzo, tiempo y recursos se requerirán. Por tanto, cualquier
estrategia de prueba debe incorporar la planificación de la prueba,
el diseño de casos de prueba, la ejecución de la prueba y la
recolección y evaluación de los resultados.
Una estrategia de prueba de software debe ser suficientemente
flexible para promover un uso personalizado de la prueba. Al mismo
tiempo, debe ser suficientemente rígida para alentar la planificación
razonable y el seguimiento de la gestión conforme avanza el
proyecto.
UN ENFOQUE ESTRATÉGICO PARA LA PRUEBA DE SOFTWARE

La prueba es un conjunto de actividades que pueden planearse por
adelantado y realizarse de manera sistemática. Por esta razón,
durante el proceso de software, debe definirse una plantilla para la
prueba del software: un conjunto de pasos que incluyen métodos
de prueba y técnicas de diseño de casos de prueba específicos.
En la literatura sobre el tema, se han propuesto algunas estrategias
de prueba de software. Todas proporcionan una plantilla para la
prueba y tienen las siguientes características genéricas:
• Para realizar una prueba efectiva, debe realizar revisiones técnicas
efectivas. Al hacerlo, eliminará muchos errores antes de comenzar
la prueba.
• La prueba comienza en los componentes y opera “hacia afuera”,
hacia la integración de todo el sistema de cómputo.
• Diferentes técnicas de prueba son adecuadas para distintos
enfoques de ingeniería de software y en diferentes momentos en el
tiempo.
• Las pruebas las realiza el desarrollador del software y (para
proyectos grandes) un grupo de prueba independiente (GPI).

•Prueba y depuración son actividades diferentes, pero la
depuración debe incluirse en cualquier estrategia de prueba.
Una estrategia para la prueba de software debe incluir pruebas de
bajo nivel, que son necesarias para verificar que un pequeño
segmento de código fuente se implementó correctamente, así
como pruebas de alto nivel, que validan las principales funciones
del sistema a partir de los requerimientos del cliente. Una
estrategia debe proporcionar una guía para el profesional y un
conjunto de guías para el jefe de proyecto. Puesto que los pasos de
la estrategia de prueba ocurren cuando comienza a aumentar la
presión por las fechas límite, el avance debe ser medible y los
problemas deben salir a la superficie tan pronto como sea posible.
Organización de las pruebas del software

En todo proyecto de software hay un conflicto inherente de
intereses que ocurre conforme comienzan las pruebas. Hoy en día,
a las personas que construyen el software se les pide probarlo. En
sí, esto parece sencillo; después de todo, ¿quién conoce mejor el
programa que sus desarrolladores?.
Por desgracia, estos mismos desarrolladores tienen mucho interés
en demostrar que el programa está libre de errores, que funciona
de acuerdo con los requerimientos del cliente y que se completará
a tiempo y dentro del presupuesto. Cada uno de estos intereses
tiene un efecto negativo sobre las pruebas más cuidadosas.
Desde un punto de vista psicológico, el análisis y diseño de software
(junto con la codificación) son tareas constructivas. El ingeniero de
software analiza, modela y luego crea un programa de
computadora y su documentación. Como cualquier constructor, el
ingeniero de software está orgulloso del edificio que construyó y ve
con desconfianza a quien intente derrumbarlo.

Cuando comienzan las pruebas, hay un sutil, pero definitivo, intento
por “romper” lo que construyó el ingeniero de software. Desde el
punto de vista del constructor, las pruebas pueden considerarse
como (psicológicamente) destructivas. De modo que el constructor
actuará con cuidado, y diseñará y ejecutará pruebas que
demostrarán que el programa funciona, en lugar de descubrir
errores. Desafortunadamente, los errores estarán presentes. Y si el
ingeniero de software no los encuentra, ¡el cliente lo hará!
El desarrollador de software siempre es responsable de probar las
unidades individuales (componentes) del programa y de asegurarse
de que cada una desempeña la función o muestra el
comportamiento para el cual se diseñó. En muchos casos, el
desarrollador también realiza pruebas de integración, una etapa en
las pruebas que conduce a la construcción (y prueba) de la
arquitectura completa del software. Sólo después de que la
arquitectura de software está completa se involucra un grupo de
prueba independiente (GPI).
El papel de un grupo de prueba independiente (GPI) es remover los
problemas inherentes que están asociados con dejar al constructor
probar lo que construyó. Las pruebas independientes remueven el
conflicto de intereses que de otro modo puede estar presente.
Después de todo, al personal del GPI se le paga por encontrar
errores.
Sin embargo, el desarrollador no da el software al GPI y se retira. Él
y el GPI trabajan de manera cercana a lo largo del proyecto de
software para garantizar que se realizarán pruebas lo más
exhaustivas posible. Mientras se realizan éstas, el desarrollador
debe estar disponible para corregir los errores que se descubran.

Cada vez que se analiza la prueba del software, surge una pregunta
clásica: “¿cuándo terminan las pruebas?, ¿cómo se sabe que se ha
probado lo suficiente?”. Lamentablemente, no hay una respuesta
definitiva a esta pregunta, pero existen algunas respuestas
pragmáticas e intentos tempranos a manera de guía empírica.
Una respuesta a la pregunta es: “nunca se termina de probar; la
carga simplemente pasa de usted (el ingeniero de software) al
usuario final”. Cada vez que el usuario ejecuta un programa de
computadora, el programa se pone a prueba. Este instructivo hecho
subraya la importancia de otras actividades a fin de garantizar la
calidad del software. Otra respuesta (un tanto cínica, mas no
obstante precisa) es: “las pruebas terminan cuando se agota el
tiempo o el dinero”.
Aunque algunos profesionales usarían estas respuestas, se
necesitan criterios más rigurosos para determinar cuándo se han
realizado suficientes pruebas. Se pueden mencionar enfoques que
sugieren el uso de técnicas estadísticas que ejecutan una serie de
pruebas derivadas de una muestra estadística de todas las posibles
ejecuciones de programa por parte de todos los usuarios de una
población objetivo. Otros abogan por el uso del modelado
estadístico y la teoría de confiabilidad del software para predecir
cuándo están completas las pruebas.
Al coleccionar estadísticas durante las pruebas del software y usar
los modelos existentes de confiabilidad del mismo, es posible
desarrollar lineamientos significativos para responder la pregunta:
“¿cuándo terminan las pruebas?”. Hay poco debate acerca de que
todavía queda mucho trabajo por hacer antes de poder establecer
reglas cuantitativas para las pruebas, pero los acercamientos
empíricos que existen en la actualidad son considerablemente
mejores que la intuición pura.

“Nunca se dará suficiente importancia a las pruebas del software y
sus implicaciones en la calidad del software” (Deutsch/79).
El desarrollo de sistemas de software implica una serie de

actividades de producción en las que las posibilidades de que
aparezca el fallo humano son enormes. Los errores pueden
empezar a darse desde el primer momento del proceso. Debido a la
imposibilidad humana de trabajar y comunicarse de forma perfecta;
el desarrollo de software ha de ir acompañado de una actividad que
garantice la calidad.
Las pruebas del software son un elemento crítico para la garantía
de calidad del software y representa una revisión final de las
especificaciones, del diseño y de la codificación.
La creciente percepción del software como un elemento del
sistema y la importancia de los costos asociados a un fallo del
propio sistema, están motivando la creación de pruebas minuciosas
y bien planificadas. No es raro que una organización de desarrollo
de software emplee entre el 30 y el 40% del esfuerzo total de un
proyecto en las pruebas. En casos extremos, las pruebas del
software para actividades críticas pueden costar ¡de tres a cinco
veces más que el resto de los pasos de la ingeniería del software
juntos!
En todo proyecto de software, aproximadamente entre el 40 y el

50% del tiempo y más de la mitad del costo son empleados en
probar el programa o el sistema.
Una cuestión muy importante es la correcta definición del término
probar.
Se parte de la idea de que se usa con gran frecuencia una definición
totalmente incorrecta de la palabra probar.

Algunas de estas definiciones son las siguientes:
• Probar es demostrar que no hay errores presentes en un
programa.
• El propósito de probar es mostrar que el programa realiza
correctamente las funciones esperadas.
• Probar es el proceso que lleva a confiar en que un programa hará
lo que se supone que debe hacer.
Estas definiciones son incorrectas porque describen casi lo opuesto

de lo que debemos considerar como prueba de programa.
Cuando se prueba un programa se desea agregarle un valor, lo que
significa aumentar su calidad o su confiabilidad; lo que a su vez
significa encontrar y eliminar errores.
De aquí que no se deba probar un programa para mostrar que
funciona; es conveniente comenzar con la suposición de que el
programa contiene errores y luego probar el programa para
encontrar tantos errores como sea posible.
En consecuencia, una definición más apropiada sería: “Prueba es el
proceso de ejecutar un programa con el fin de encontrar errores”.
Si nuestra meta es demostrar que el programa no tiene errores
tenderemos a seleccionar datos de prueba con baja probabilidad de
hacer que el programa falle. En cambio, si nos proponemos
demostrar que el programa tiene fallas, nuestros datos de prueba
tendrán una mayor probabilidad de lograrlo. Ello implica que la
prueba es un proceso destructivo, lo que explica porque resulta tan
difícil.
Un caso de prueba exitoso es el que descubre un error y un caso
de prueba no exitoso es el que hace que el programa produzca un
resultado correcto.

Es el proceso de ejecutar un programa con determinados datos de
entrada con el fin de encontrar errores mediante la identificación
de las diferencias entre los resultados obtenidos y los resultados
esperados a partir de los datos de prueba introducidos como
entrada.
La prueba del software es un elemento de un tema más amplio que
se conoce como verificación y validación (V y V)
Verificación: ¿Estamos construyendo el producto correctamente?
Validación: ¿Estamos construyendo el producto correcto?
La verificación es el conjunto de actividades que aseguran que el

software implementa correctamente una función específica.
La validación se refiere al conjunto de actividades que aseguran
que el software construido se ajusta a los requerimientos del
cliente.
Las pruebas constituyen una técnica para la validación y la
verificación (V y V) del software.
No se debe probar un programa para mostrar que funciona, es
conveniente comenzar con la suposición de que contiene errores y
luego probarlo para encontrar tantos como sea posible.
Las pruebas presentan una interesante anomalía para el ingeniero
del software. El ingeniero crea una serie de casos de prueba que
intentan “demoler” el software construido. De hecho, las pruebas
son uno de los pasos de la ingeniería del software que se pueden
ver (por lo menos de manera psicológica) como destructivo en lugar
de constructivo.
Los ingenieros del software son, por naturaleza, personas
constructivas. Las pruebas requieren que se descarten ideas
preconcebidas sobre la “corrección” del software que acaba de
desarrollar y se supere cualquier conflicto de intereses que
aparezca cuando se descubran errores.

La prueba es el proceso de ejecución de un programa con el fin de
descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad
de encontrar errores no descubiertos hasta entonces.
Una prueba tiene éxito si descubre un error no detectado antes.
Un caso de prueba exitoso es el que descubre un error y un caso

de prueba no exitoso es el que hace que el programa produzca un
resultado correcto.
Consideremos la analogía con el caso de una persona que visita al
médico a raíz de una sensación general de malestar. Si el doctor
ordena una serie de pruebas de laboratorio que no ayudan a ubicar
el problema, no diremos que los análisis son “exitosos”; ellos fueron
“no exitosos” puesto que el paciente gastó en las pruebas y todavía
está enfermo y empieza a cuestionar la habilidad del médico para
diagnosticar.
Sin embargo, si un análisis determina que el paciente padece una
enfermedad determinada, se dice que la prueba es exitosa puesto
que el doctor ahora puede prescribir un tratamiento adecuado.
La analogía identifica al paciente con el programa enfermo.
Los objetivos anteriores suponen un cambio en nuestro punto de
vista, nos quitan la idea que normalmente se tiene de que una
prueba tiene éxito si no descubre errores.
El objetivo es diseñar pruebas que saquen a la luz diferentes clases
de errores haciéndolo con la menor cantidad de tiempo y esfuerzo.
Además los datos que se van recogiendo a medida que se lleva a
cabo la prueba proporcionan una buena indicación de la fiabilidad
del software y de la calidad del software como un todo.
“La prueba no puede asegurar la ausencia de defectos; sólo puede

demostrar que existen defectos en el software”.

Las pruebas permiten la rectificación del software. Todos
cometemos errores. Diversos estudios señalan una media de un
error por cada cien sentencias para un trabajo de programación
bien realizado. Llegar a una tasa del 10% de errores, evidentemente
obliga a plantear una formación en programación.
Principios de la prueba
Para la aplicación de métodos para el diseño de casos de prueba
efectivos, un ingeniero de software deberá conocer los principios
básicos que guían las pruebas del software. Es posible, sin embargo,
asegurarse de que se han aplicado todas las condiciones del diseño
de pruebas.
Las consideraciones generales, más comunes, a toda prueba son:
1) A todas las pruebas se les debería poder hacer un seguimiento
hasta los requisitos del cliente.
Se entiende que los defectos más graves (desde el punto de vista
del cliente) son aquellos que impiden al programa cumplir sus
requisitos.
2) Las pruebas deberían planificarse mucho antes de que
empiecen.
Una vez completado el modelo de requisitos, es recomendable
comenzar con la planificación de las pruebas; y luego de consolidar
el modelo de diseño, podemos comenzar con la definición detallada
de los casos de prueba. Por tanto, se puede planificar y diseñar
todas las pruebas antes de generar ningún código.
3) Las pruebas deben empezar por “lo pequeño” y progresar hacia
“lo grande”.
4) No son posibles pruebas completamente exhaustivas.
El número de permutaciones de caminos para incluso un programa
de tamaño moderado es excepcionalmente grande. Por este
motivo, es imposible ejecutar todas las combinaciones de caminos
durante las pruebas.

Es posible, sin embargo, cubrir adecuadamente la lógica del
programa y asegurarse de que se han aplicado todas las
condiciones en el diseño a nivel del componente.
5) Cada caso de prueba debe definir el resultado de salida
esperado.
Este resultado se debe comparar con el resultado que realmente se
obtenga de la ejecución con los datos de prueba como entrada.
Por ello, un caso de prueba debe constar de dos componentes:
a) Descripción de los datos de entrada al programa.
b) Descripción de la salida esperada para esos datos de prueba.
6) El programador debe evitar probar sus proyectos completos.
Esto porqué resulta muy difícil para un programador, que ha sido
constructivo durante todo el tiempo, cambiar súbitamente y
adoptar una actitud totalmente destructiva con respecto a su
mismo programa.
Además el programa puede contener errores debido a una falsa
interpretación del enunciado del problema; en consecuencia es de
esperar que tenga la misma falsa interpretación cuando intente
probar su programa.
7) Una empresa no debería probar sus propios programas.
8) Inspeccionar con detalle el resultado de cada prueba.
Un importante número de errores son los errores expuestos
previamente por casos de prueba pero que escaparon a la
detección debido a fallas en la inspección cuidadosa de los
resultados de esos casos de prueba.
Es frecuente pasar por alto síntomas claros.
9) Deben incluirse tanto entradas inválidas e inesperadas como
entradas válidas y esperadas.
Ya que por lo general existe una tendencia natural a centrarse en lo
esperado y lo válido.

10) Se debe examinar el programa para comprobar:
a) Que no hace lo que se supone que debe hacer.
b) Si hace lo que no se supone que debe hacer.
El objetivo es siempre tratar de demostrar que el programa puede
fallar en un aspecto y/o en otro.
11) Evite los casos de prueba desechables a menos que el
programa sea verdaderamente desechable.
Por ejemplo, los casos que se teclean sobre la marcha. Los casos
deben documentarse y guardarse para evitar reinventarlos cada vez
que se requiera su uso.
12) No planear pruebas suponiendo que no habrá errores.
Esto es una mala interpretación del concepto de prueba, ya que
ésta suposición errónea lleva a planificar las pruebas con pocos
recursos.
13) La probabilidad de la existencia de nuevos errores en una
sección del programa es proporcional al número de errores ya
encontrados en esa misma sección.
Es decir, que a mayor número de errores descubiertos, mayor
probabilidad de encontrar otros nuevos. Algunos expertos dicen
que esto depende de la complejidad y de la habilidad del
programador.
14) Las pruebas constituyen una tarea creativa y son un desafío
intelectual.
Es creativa porqué, aunque existan técnicas para conseguir un
conjunto razonable de casos de prueba, su aplicación requiere tanta
o más creatividad que el diseño del software y se convierte en un
desafío intelectual porqué debe recurrirse al ingenio para acercarse
al objetivo ideal de detectar la mayor cantidad de errores.

Ciclo completo de la Prueba

La figura anterior muestra el ciclo completo de las actividades
relacionadas con la prueba:
1) Comienza con la generación de un plan de pruebas, apoyándose
en la documentación sobre el proyecto y la documentación sobre el
software a probar.
2) A partir del plan de pruebas se entra, en detalle, diseñando las
pruebas específicas; basándose en la documentación del software a
probar.
3) Una vez detalladas las pruebas (especificación de casos y
procedimientos) se puede tomar la configuración del software
(revisada quizás) para ejecutar en la computadora las pruebas;
teniendo en cuenta, a efectos de notificar resultados, los posibles
defectos en el software no localizados y corregidos aún, pero con
sus síntomas ya detectados.
La configuración del software incluye:
• Especificación de los Requerimientos.
• Especificación del Diseño.
• Código Fuente.
4) A partir de los resultados de salida que produce la ejecución de
las pruebas, se pasa a la fase de evaluación (es decir comparar los
resultados de la prueba con los resultados esperados).
De ello surgen dos actividades principales:
La depuración, que se alimenta de la información sobre errores
especificados en informes y cuadernos históricos de pruebas.
El análisis de errores reflejados en las estadísticas de errores que
pretende obtener una predicción o un modelo de fiabilidad, es
decir utilizar los coeficientes de error de un modo más formal para
predecir futuras ocurrencias de errores y por lo tanto el grado de
fiabilidad.
5) La depuración puede fijar y corregir (o no) los errores. Si no
consigue localizarlos, pueden realizarse pruebas adicionales que
ayuden a su fijación (notificando los defectos que se persiguen).

La facilidad de prueba del software es simplemente la facilidad con
la que se puede probar un programa de computadora. Como la
prueba es tan profundamente difícil, merece la pena saber qué se
puede hacer para hacerlo más sencillo.
La siguiente lista de comprobación proporciona un conjunto de
características que llevan a un software fácil de probar:
• Operatividad: “Cuanto mejor funcione, más eficientemente

se puede probar”.
• Observabilidad: “Lo que ves es lo que pruebas”.
• Controlabilidad: “Cuanto mejor podamos controlar el

software, más se puede automatizar y optimizar”.
• Capacidad de descomposición: “Controlando el ámbito de

las pruebas, podemos aislar más rápidamente los problemas y
llevar a cabo mejores pruebas de regresión”.
• Simplicidad: “Cuanto menos haya que probar, más

rápidamente podremos probarlo”.
• Estabilidad: “Cuanto menos cambios, menos interrupciones

a las pruebas”.
• Facilidad de compresión: “Cuanta más información

tengamos, más inteligentes serán las pruebas”.

Atributos de una “buena” prueba
Una buena prueba tiene una alta probabilidad de encontrar un

error. Para alcanzar este objetivo, el responsable de la prueba debe
entender el software e intentar desarrollar una imagen mental de
cómo podría fallar el software.
Una prueba no debe ser redundante. El tiempo y los recursos para

las pruebas son limitados. No hay motivo para realizar una prueba
que tiene el mismo propósito que otra. Todas las pruebas deberían
tener un propósito diferente (incluso si es sutilmente diferente).
Una buena prueba debería ser “la mejor de la cosecha”. En un

grupo de pruebas que tienen propósito similar, las limitaciones de
tiempo y recursos pueden abogar por la ejecución de sólo un
subconjunto de estas pruebas. En tales casos, se debería emplear la
prueba que tenga la más alta probabilidad de descubrir una clase
de entera de errores.
Una buena prueba no debería ser ni demasiado sencilla ni

demasiado compleja. Aunque es posible a veces combinar una serie
de pruebas en un caso de prueba, los posibles efectos secundarios
de este enfoque pueden enmascarar errores. En general, cada
prueba debería realizarse separadamente.

Actividades de la fase de planificación
En general la fase de planificación de cualquier etapa de prueba

requiere las siguientes actividades:
•Designación del responsable de la etapa.

•Identificación de los participantes en la etapa y sus roles.
•Identificación y planificación de los recursos requeridos.
•Estimación del tiempo y esfuerzo requerido.
•Documentación del alcance de las pruebas.
•Documentación de la filosofía de diseño de los casos de prueba.
•Generación disciplinada y sistemática de casos de prueba, según la
filosofía adoptada.
•Documentación de los casos de prueba. Para cada caso de prueba
la documentación debe incluir:
•Justificación de su inclusión.
•Datos de entrada e indicaciones de cómo correr el caso.
•Configuración requerida para la prueba.
•Resultados esperados.
•(En ejecución se agrega) Resultados obtenidos.
•(En ejecución se agrega) Tipo de defecto hallado. Esto puede
constar de una indicación de superada o cómo mínimo una
indicación de la severidad de la falla (falla grave, seria o
menor), una descripción de la falla y una identificación
tentativa de la etapa del desarrollo a que se atribuye (Análisis,
Diseño, Codificación, etc.)
• Criterio de culminación de las pruebas.

TESTING
TEMA: Pruebas de Unidad,

Integración y Sistema

La prueba de unidad enfoca los esfuerzos de verificación en la
unidad más pequeña del diseño de software: el componente o
módulo de software. Al usar la descripción del diseño de
componente como guía, las rutas de control importantes se
prueban para descubrir errores dentro de la frontera del módulo. La
relativa complejidad de las pruebas y los errores que descubren
están limitados por el ámbito restringido que se establece para la
prueba de unidad. Las pruebas de unidad se enfocan en la lógica de
procesamiento interno y de las estructuras de datos dentro de las
fronteras de un componente.
Consideraciones de las pruebas de unidad.
Las pruebas que se dan como parte de la prueba de unidad están
esquemáticamente ilustradas en la siguiente figura:
Se prueba la interfaz del módulo para asegurar que la información

fluye de forma adecuada hacia y desde la unidad de programa que
está siendo probada. Se examinan las estructuras de datos locales
para asegurar que los datos que se mantienen temporalmente
conservan su integridad durante todos los pasos de ejecución del
algoritmo.

Se prueban las condiciones límite para asegurar que el módulo
funciona correctamente en los límites establecidos como
restricciones de procesamiento.
Se ejercitan todos los caminos independientes (caminos básicos)
de la estructura de control para asegurar que todas las sentencias
del módulo se ejecutan por lo menos una vez. Y finalmente se
prueban todos los caminos de manejo de errores.
El flujo de datos a través de la interfaz de un componente se prueba

antes de iniciar cualquiera otra prueba. Si los datos no entran y
salen de manera adecuada, todas las demás pruebas son
irrelevantes. Además, deben ejercitarse las estructuras de datos
locales y averiguarse (si es posible) el impacto local sobre los datos
globales durante las pruebas de unidad.
La prueba selectiva de las rutas de ejecución es una tarea esencial
durante la prueba de unidad.
Los casos de prueba deben diseñarse para descubrir errores
debidos a cálculos erróneos, comparaciones incorrectas o flujo de
control inadecuado.
Las pruebas de límite o frontera son una de las tareas de prueba de
unidad más importantes. Con frecuencia, el software falla en sus
fronteras. Es decir: con frecuencia los errores ocurren cuando se
procesa el enésimo elemento de un arreglo ene-dimensional,
cuando se invoca la enésima repetición de un bucle con n pasadas,
cuando se encuentra el valor máximo o mínimo permisible.
Un buen diseño anticipa las condiciones de error y establece rutas
de manejo de errores para enrutar o terminar limpiamente el
procesamiento cuando ocurre un error. Desafortunadamente, hay
una tendencia a incorporar el manejo de errores en el software y
luego nunca probarlo.

Procedimiento de la prueba de unidad
Normalmente se considera a la prueba de unidad como algo
adjunto al paso de codificación.
El diseño de casos de prueba de unidad comienza una vez que se ha
desarrollado, revisado y verificado, en su sintaxis, el código a nivel
de fuente.
Cada caso de prueba debe ir acompañado de un conjunto de
resultados esperados.
Debido a que un módulo no es un programa independiente, se
debe desarrollar para cada prueba de unidad un software que
controle y/o resguarde.
En la siguiente figura se muestra el entorno de la prueba de unidad:
En la mayoría de las aplicaciones, un conductor no es más que un

programa principal que acepta los datos del caso de prueba, pasa
estos datos al módulo (a ser probado) e imprime los resultados
importantes.

Los resguardos sirven para reemplazar módulos que están
subordinados (“llamados por”) al módulo que hay que probar. Un
resguardo o un subprograma simulado usa la interfaz del módulo
subordinado, lleva a cabo una mínima manipulación de datos,
imprime una verificación de entrada y vuelve.
Los conductores y los resguardos son una sobrecarga de trabajo. Es
decir, ambos son software que debe desarrollarse pero que no se
entrega con el producto software final.
La prueba de unidad se simplifica cuando se diseña un módulo con
un alto grado de cohesión. Cuando un módulo sólo se dirige a una
función, se reduce el número de casos de prueba y los errores se
pueden predecir y descubrir más fácilmente.

Por lo general, los informáticos se preguntan, “si todos los módulos
funcionan bien por separado, ¿por qué dudar que funcionen bien
todos juntos?”. El problema es justamente eso: “ponerlos todos
juntos” (es decir la interacción entre ellos, conectarlos en resumen).
Los datos se pueden perder en una interfaz; un componente puede
tener un inadvertido efecto adverso sobre otro; las subfunciones,
cuando se combinan, pueden no tener la función principal deseada;
las estructuras de datos globales pueden presentar problemas, etc.
Lamentablemente, la lista sigue y sigue.
La prueba de integración es una técnica sistemática para construir
la estructura del programa, mientras que al mismo tiempo se llevan
a cabo pruebas para detectar errores asociados con la interacción.
El objetivo es tomar los módulos probados en unidad y construir
una estructura de programa que esté de acuerdo al diseño.
Con frecuencia existe una tendencia a intentar la integración no
incremental, es decir, a construir el programa usando un enfoque
de big bang. Todos los componentes se combinan por adelantado.
Todo el programa se prueba como un todo. ¡Y usualmente resulta el
caos! Se descubre un conjunto de errores. La corrección se dificulta
pues el aislamiento de las causas se complica por la vasta extensión
de todo el programa. Una vez corregidos estos errores, otros
nuevos aparecen y el proceso continúa en un bucle aparentemente
interminable.
La integración incremental es la antítesis del enfoque big bang. El
programa se construye y prueba en pequeños incrementos, donde
los errores son más fáciles de aislar y corregir; las interfaces tienen
más posibilidades de probarse por completo; y puede aplicarse un
enfoque de prueba sistemático.
Existen diferentes estrategias de integración incremental.

Integración descendente
Es un planteamiento incremental a la construcción de la estructura
de programas. Se integran los módulos moviéndose hacia abajo en
la jerarquía de control, comenzando por el módulo de control
principal (programa principal). Los módulos subordinados al
módulo principal se van incorporando a la estructura bien de forma
primero-en-profundidad, (se mueve verticalmente en la estructura
del programa) o bien en la forma primero-en-anchura (se mueve
horizontalmente en la estructura).
Como se muestra en la siguiente figura:
No hay una secuencia óptima de integración. Debe estudiarse el

problema concreto y buscar el orden de integración más adecuado.
La integración primero-en-profundidad integra todos los módulos
de un camino de control principal de la estructura.
La elección del camino principal es, de alguna manera, arbitraria y
dependerá de las características específicas de la aplicación.
Por ejemplo, si se elige el camino a mano izquierda, se integrarán
primero los módulos M1, M2 y M5. A continuación se integrarán M8
o M6 (si es necesario para un funcionamiento adecuado de M2).
Luego se construyen los caminos de control central y derecho.
La integración primero-en-anchura incorpora todos los módulos
directamente subordinados a cada nivel, moviéndose en la
estructura de forma horizontal. Según el gráfico, los primeros
módulos que se integran son: M2, M3 y M4. A continuación sigue el
siguiente nivel de control, M5, M6, etc.
El proceso de integración se realiza en una serie de cinco pasos:
1. Se usa el módulo de control principal como controlador de la
prueba (impulsor), disponiendo de resguardos (módulos ficticios)
para todos los módulos directamente subordinados al módulo de
control principal.
2. Dependiendo del enfoque de integración elegido se van
sustituyendo los resguardos subordinados, uno a uno, por los
módulos reales.
3. Se llevan a cabo pruebas cada vez que se integra un nuevo
módulo.
4. Tras terminar cada conjunto de pruebas, se reemplaza cada
resguardo con el módulo real.
5. Se hace la prueba de regresión (repetir casos de prueba) para
asegurarse de que no se han introducido errores nuevos.
El proceso continúa desde el paso 2 hasta que se haya construido la
estructura del programa entero.
La estrategia descendente parece relativamente fácil, pero en la
práctica, pueden sufrir algunos problemas.
El más común de éstos se da cuando se requiere un proceso, de los
niveles más bajos de la jerarquía, para poder probar
adecuadamente los niveles superiores.
Al principio de la prueba descendente los módulos de bajo nivel se
reemplazan por resguardos; por lo tanto, no pueden fluir datos
significativos hacia arriba por la estructura del programa.
El responsable de la prueba tiene tres opciones:

1. Retrasar muchas de las pruebas hasta que los resguardos sean
reemplazados por los módulos reales.
2. Desarrollar resguardos que realicen funciones limitadas y que
simulen los módulos reales.
3. Integrar el software desde el fondo de la jerarquía y hacia arriba.
El primer enfoque (retrasar pruebas hasta reemplazar los

resguardos por los módulos reales) hace que perdamos cierto
control sobre la correspondencia entre pruebas específicas y la
incorporación de módulos específicos. Esto puede conducir a
dificultades para determinar la causa de los errores y tiende a violar
la naturaleza enormemente restrictiva del enfoque descendentela.
El segundo enfoque es factible pero puede llevar a un significativo
incremento del esfuerzo a medida que los resguardos se hagan más
complejos.
El tercer enfoque es la denominada prueba ascendente
(Integración ascendente).

Integración ascendente
Esta prueba, como su nombre lo indica, empieza la construcción y la
prueba, con módulos atómicos (es decir, módulos de los niveles
más bajos de la estructura del programa). Ya que los módulos se
integran de abajo hacia arriba, el proceso requerido de los módulos
subordinados a un nivel dado siempre están disponibles y se
elimina la necesidad de resguardos.
Se puede implementar una estrategia de integración ascendente
mediante los siguientes pasos:
1. Se combinan los módulos de bajo nivel en grupos (a veces
denominados construcciones o builds) que realicen una subfunción
específica del software.
2. Se escribe un controlador (un programa de control de la prueba)
para coordinar la entrada y la salida de los casos de prueba.
3. Se prueba el grupo.
4. Se eliminan los controladores (impulsores) y se combinan los
grupos moviéndose hacia arriba por la estructura del programa.
La integración sigue el siguiente esquema:

Se combinan los módulos para formar los grupos 1, 2 y 3. Cada uno
de los grupos se somete a prueba mediante un controlador (bloque
punteado). Los módulos de los grupos 1 y 2 se subordinan a Ma.
Los controladores D1 y D2 se eliminan y los grupos interaccionan
directamente con Ma.
De forma similar se elimina el controlador D3 del grupo 3, antes de
la integración con el módulo Mb. Tanto Ma como Mb se integrarán
finalmente con el módulo Mc y así sucesivamente.
A medida que la integración progresa hacia arriba, disminuye la
necesidad de controladores de prueba diferentes.
Prueba de regresión
Cada vez que se añade un nuevo módulo como parte de una
prueba de integración, el software cambia. Se establecen nuevos
caminos de flujo de datos, pueden ocurrir nuevas E/S y se invoca
una nueva lógica de control.
Estos cambios pueden causar problemas con funciones que antes
trabajaban bien. En el contexto de una estrategia de prueba de
integración, la prueba de regresión es volver a ejecutar un
subconjunto de pruebas que se han llevado a cabo anteriormente
para asegurarse de que los cambios no han propagado efectos
colaterales no deseados.
Las pruebas con éxito dan como resultado el descubrimiento de
errores que hay que corregir. Cuando se corrige el software, se
cambia algún aspecto de la configuración del software, ya sea el
programa, su documentación o los datos que lo soportan.
La prueba de regresión es la actividad que ayuda a asegurar que los
cambios no introducen un comportamiento no deseado del
programa o errores adicionales.

La prueba de regresión se puede hacer manualmente, es decir,
volviendo a ejecutar un subconjunto de todos los casos de prueba o
utilizando herramientas automatizadas de reproducción/captura,
que permiten, a los ingenieros de software, capturar casos de
prueba y los resultados para la subsiguiente reproducción y
comparación.
El conjunto de pruebas de regresión contiene tres clases diferentes
de casos de prueba:
1. Una muestra representativa de pruebas que ejercite todas las
funciones del software.
2. Pruebas adicionales que se centran en las funciones del software
que se van a ver probablemente afectadas por el cambio.
3. Pruebas que se centran en los componentes del software que
han cambiado.
Conclusión
En general, las ventajas de una estrategia tienden a convertirse en
desventajas para la otra estrategia.
La principal desventaja para el enfoque descendente es la
necesidad de resguardos y las dificultades de prueba que pueden
estar asociados con ellos.
Pero esto queda compensado con la ventaja de poder probar de
antemano las principales funciones de control.
La principal desventaja de la integración ascendente es que “el
programa como entidad no existe hasta que se ha añadido el último
módulo (según Myer)”.
Este inconveniente se compensa con la mayor facilidad de diseño
de casos de prueba y con la falta de resguardos.

Práctica recomendada
La selección de una estrategia de integración depende de las
características del software y, a veces, de la planificación del
proyecto.
En general el mejor compromiso puede ser un enfoque combinado
que use la integración descendente para los niveles superiores de la
estructura del programa, junto con la integración ascendente para
los niveles subordinados.
La práctica de integración recomendada se basa en:
Aproximación combinada (o prueba sándwich) que actúa de la
siguiente manera:
•Comienza en los módulos de niveles superiores de forma
descendente.
•Comienza también, a la vez, de forma ascendente en los
niveles inferiores.
•Encuentro de ambas aproximaciones en algún nivel
intermedio.
Conforme se realiza la integración, quien efectúa la prueba debe

identificar los módulos críticos.
Un módulo crítico tiene una o más de las siguientes características:
1) aborda muchos requerimientos de software, 2) tiene un alto
nivel de control (reside relativamente alto en la estructura del
programa), 3) es complejo o proclive al error o 4) tiene
requerimientos de rendimiento definidos. Los módulos críticos
deben probarse tan pronto como sea posible. Además, las pruebas
de regresión deben enfocarse en la función del módulo crítico.

Los criterios que deben usarse para diseñar pruebas de integración
y que se aplican a todas las fases de prueba son:
1. Integridad de interfaz. Las interfaces internas y externas se
prueban conforme cada módulo (o grupo) se incorpora en la
estructura.
2. Validez funcional. Se realizan pruebas diseñadas para descubrir
errores funcionales ocultos.
3. Contenido de la información. Se realizan pruebas diseñadas para
descubrir errores ocultos asociados con las estructuras de datos
locales o globales.
4. Rendimiento. Se realizan pruebas diseñadas para verificar los
límites del rendimiento establecidos durante el diseño del software.
Como parte del plan de prueba, también se discute un calendario
para la integración, el desarrollo de software de sobrecarga del
sistema y temas relacionados. Se establecen las fechas de inicio y
fin de cada fase y se definen “ventanas disponibles” para módulos
de prueba de unidad.
Una breve descripción del software de sobrecarga (resguardos y
controladores) se concentra en las características que pueden
requerir de un esfuerzo especial. Finalmente, se describe el entorno
y los recursos de la prueba. Configuraciones inusuales de hardware,
simuladores peculiares y herramientas o técnicas de prueba
especial son algunos de los muchos temas que también pueden
analizarse.

Estrategias de prueba para software OO
Enunciado de manera simple, el objetivo de probar es encontrar el
mayor número posible de errores con una cantidad manejable de
esfuerzo aplicado durante un lapso realista. Aunque este objetivo
fundamental se mantiene invariable para el software orientado a
objeto, la naturaleza de este software cambia tanto la estrategia
como las tácticas de la prueba.
Prueba de unidad en el contexto OO
Cuando se considera software orientado a objeto, el concepto de
unidad cambia. La encapsulación determina la definición de clases y
objetos. Esto significa que cada clase y cada instancia de una clase
empaqueta los atributos (datos) y las operaciones que manipulan
estos datos. La prueba de clase para software OO es el equivalente
de la prueba de unidad para software convencional. A diferencia de
la prueba de unidad del software convencional, que tiende a
enfocarse sobre el detalle algorítmico de un módulo y en los datos
que fluyen a través de la interfaz de módulo, la prueba de clase
para software OO la dirigen las operaciones encapsuladas por la
clase y el comportamiento de estado de ésta.
Prueba de integración en el contexto OO
Existen dos estrategias diferentes para la prueba de integración de
los sistemas OO. La primera, la prueba basada en hebra, integra el
conjunto de clases requeridas para responder a una entrada o
evento para el sistema. Cada hebra se integra y prueba de manera
individual. La prueba de regresión se aplica para asegurar que no
ocurran efectos colaterales. El segundo enfoque de integración, la
prueba basada en uso, comienza la construcción del sistema al
probar dichas clases (llamadas clases independientes). Después de
probar las clases independientes, se prueba la siguiente capa de
clases, llamadas dependientes, que usan las clases independientes.
Esta secuencia de probar capas de clases dependientes continúa
hasta que se construye todo el sistema.

Estrategias de prueba para probar webapps
Adopta los principios básicos para todas las pruebas de software y
aplica una estrategia y tácticas que se usan para sistemas OO. Los
siguientes pasos resumen el enfoque:
1. El modelo de contenido para la webapp se revisa para descubrir
errores.
2. El modelo de interfaz se revisa para garantizar que todos los
casos de uso pueden adecuarse.
3. El modelo de diseño para la webapp se revisa para descubrir
errores de navegación.
4. La interfaz de usuario se prueba para descubrir errores en los
mecanismos de presentación y/o navegación.
5. A cada componente funcional se le aplica una prueba de unidad.
6. Se prueba la navegación a lo largo de toda la arquitectura.
7. La webapp se implementa en varias configuraciones ambientales
diferentes y se prueba en su compatibilidad con cada configuración.
8. Las pruebas de seguridad se realizan con la intención de explotar
vulnerabilidades en la webapp o dentro de su ambiente.
9. Se realizan pruebas de rendimiento.
10. La webapp se prueba mediante una población de usuarios
finales controlada y monitoreada.
Los resultados de su interacción con el sistema se evalúan por
errores de contenido y navegación, preocupaciones de facilidad de
uso, preocupaciones de compatibilidad, así como confiabilidad y
rendimiento de la webapp.
Puesto que muchas webapps evolucionan continuamente, el
proceso de prueba es una actividad siempre en marcha, y se realiza
para apoyar al personal que usa pruebas de regresión derivadas de
las pruebas desarrolladas cuando se elaboró por primera vez la
webapp.

Las pruebas de validación comienzan en la culminación de las
pruebas de integración, cuando se ejercitaron componentes
individuales, el software está completamente ensamblado como un
paquete y los errores de interfaz se descubrieron y corrigieron. En
el nivel de validación o de sistema, desaparece la distinción entre
software convencional, software orientado a objetos y webapps.
La validación se consigue cuando el software funciona de acuerdo
con las expectativas razonables del cliente que están definidas en la
especificación de requisitos del software -un documento- que
describe todos los atributos del software visibles para el usuario.
Criterios de la Prueba de Validación
La validación del software se logra a través de una serie de pruebas
que demuestran conformidad con los requerimientos. Un plan de
prueba subraya las clases de pruebas que se van a realizar y un
procedimiento de prueba define casos de prueba específicos que se
diseñan para garantizar que: se satisfacen todos los requerimientos
de funcionamiento, se logran todas las características de
comportamiento, todo el contenido es preciso y se presenta de
manera adecuada, se logran todos los requerimientos de
rendimiento, la documentación es correcta y se satisfacen la
facilidad de uso y otros requerimientos (por ejemplo,
transportabilidad, compatibilidad, recuperación de error,
mantenimiento).
Después de realizar cada caso de prueba de validación, existen dos
posibles condiciones:
1) La característica de función o rendimiento se conforma de
acuerdo con las especificaciones y se acepta, o 2) se descubre una
desviación de la especificación y se crea una lista de deficiencias.
Las desviaciones o errores descubiertos en esta etapa en un
proyecto rara vez pueden corregirse antes de la entrega
calendarizada. Con frecuencia es necesario negociar con el cliente
para establecer un método para resolver deficiencias.

Revisión de la Configuración o Auditoría
Es un elemento importante. Es asegurarse de que todos los
elementos de la configuración del software se han desarrollado
apropiadamente, se han catalogado y están suficientemente
detallados para soportar la fase de mantenimiento durante el ciclo
de vida del software.
Pruebas Alfa y Beta
Es virtualmente imposible que un constructor de software pueda
prever cómo usará realmente el programa el usuario.
Las instrucciones para usarlo pueden malinterpretarse;
regularmente pueden usarse combinaciones extrañas de datos; la
salida que parecía clara a quien realizó la prueba puede ser
ininteligible para un usuario.
Las pruebas de aceptación se llevan a cabo para que el cliente
valide todos los requisitos. Las realiza el usuario final y puede tener
lugar a lo largo de semanas o meses, descubriendo errores que
puedan ir degradando al sistema. Si el software se desarrolla como
un producto que se va usar por muchos clientes, no es práctico
realizar pruebas de aceptación formales para cada uno de ellos.
La mayoría de los constructores de software llevan a cabo un
proceso denominado pruebas Alfa y Beta para descubrir errores
que parezcan que sólo el usuario final puede descubrir.
La prueba Alfa se lleva a cabo en el lugar de desarrollo pero por un
cliente. Se usa el software de manera natural con el desarrollador
como observador de usuario y registrando los errores y los
problemas de uso. Se lleva a cabo en un entorno controlado.
La prueba Beta se lleva acabo por los usuarios finales del software
en los lugares de trabajo de los clientes. El desarrollador no está
presente normalmente. Es una aplicación <en vivo> del software en
un entorno que no puede ser controlado por el desarrollador. El
cliente registra todos los problemas (reales o imaginarios) e
informa, a intervalos regulares, al desarrollador.

Como resultado de los problemas reportados durante las pruebas
beta, es posible hacer modificaciones y luego preparar la liberación
del producto de software a toda la base de clientes.
En ocasiones se realiza una variación de la prueba beta, llamada

prueba de aceptación del cliente, cuando el software se entrega a
un cliente bajo contrato. El cliente realiza una serie de pruebas
específicas con la intención de descubrir errores antes de aceptar el
software del desarrollador.
En algunos casos (por ejemplo, una empresa, un grupo corporativo
u organismo gubernamental) la prueba de aceptación puede ser
muy formal y abarcar muchos días o incluso semanas de prueba.

Está realmente constituida por una serie de pruebas diferentes
cuyo propósito primordial es ejercitar profundamente el sistema
basado en computadora.
Aunque cada prueba tiene un propósito diferente, todas trabajan
para verificar que se han integrado adecuadamente todos los
elementos del sistema y que se realicen las funciones asignadas.
A. Prueba de Recuperación
Muchos sistemas basados en computadora deben recuperarse de
fallas y reanudar el procesamiento con poco o ningún tiempo de
inactividad. En algunos casos, un sistema debe ser tolerante a las
fallas, es decir, las fallas del procesamiento no deben causar el cese
del funcionamiento del sistema global. En otros casos, la falla de un
sistema debe corregirse dentro de un periodo de tiempo específico
u ocurrirán severos daños económicos.
La recuperación es una prueba del sistema que fuerza al software a
fallar en varias formas y que verifica que la recuperación se realice
de manera adecuada. Si la recuperación es automática (realizada
por el sistema en sí), se evalúa el reinicio, los mecanismos de
puntos de verificación, la recuperación de datos y la reanudación
para correcciones. Si la recuperación requiere intervención
humana, se evalúa el tiempo medio de reparación (TMR) para
determinar si está dentro de límites aceptables.
B. Prueba de Seguridad
Cualquier sistema basado en computadora que gestione
información sensible o cause acciones que puedan dañar (o
beneficiar) de manera inadecuada a individuos es un blanco de
penetración inadecuada o ilegal. La penetración abarca un amplio
rango de actividades: hackers que intentan penetrar en los sistemas
por deporte, empleados resentidos que intentan penetrar por
venganza, individuos deshonestos que intentan penetrar para
obtener ganancia personal ilícita.

La prueba de seguridad intenta verificar que los mecanismos de
protección que se construyen en un sistema en realidad lo
protegerán de cualquier penetración impropia. Para citar a Beizar:
“La seguridad del sistema debe, desde luego, probarse para ser
invulnerable ante ataques frontales; pero también debe probarse su
invulnerabilidad contra ataques laterales y traseros”. Durante la
prueba de seguridad, quien realiza la prueba juega el papel del
individuo que desea penetrar al sistema. ¡Cualquier cosa vale!
Quien realice la prueba puede intentar adquirir contraseñas por
medios administrativos externos; puede atacar el sistema con
software a la medida diseñado para romper cualquier defensa que
se haya construido; puede abrumar al sistema, y por tanto negar el
servicio a los demás; puede causar a propósito errores del sistema
con la esperanza de penetrar durante la recuperación; puede
navegar a través de datos inseguros para encontrar la llave de la
entrada al sistema.
Con los suficientes tiempo y recursos, las buenas pruebas de
seguridad a final de cuentas penetran en el sistema. El papel del
diseñador de sistemas es hacer que el costo de la penetración sea
mayor que el valor de la información que se obtendrá.
C. Prueba de Esfuerzo
Los primeros pasos de la prueba del software dieron como
resultado una evaluación extensa de las funciones y el rendimiento
normales del programa. Las pruebas de esfuerzo se diseñan para
enfrentar los programas con situaciones anormales. En esencia, la
persona que realiza las pruebas de esfuerzo pregunta: “¿cuánto
podemos doblar esto antes de que se rompa?”.

La prueba de esfuerzo ejecuta un sistema en forma que demanda
recursos en cantidad, frecuencia o volumen anormales. Por
ejemplo, pueden 1) diseñarse pruebas especiales que generen diez
interrupciones por segundo, cuando una o dos es la tasa promedio,
(2) aumentarse las tasas de entrada de datos en un orden de
magnitud para determinar cómo responderán las funciones de
entrada, 3) ejecutarse casos de prueba que requieran memoria
máxima y otros recursos, 4) diseñarse casos de prueba que puedan
causar thrashing (que es un quebranto del sistema por
hiperpaginación) en un sistema operativo virtual, 5) crearse casos
de prueba que puedan causar búsqueda excesiva por datos
residentes en disco. En esencia, la persona que realiza la prueba
intenta romper el programa.
Una variación de la prueba de esfuerzo es una técnica llamada
prueba de sensibilidad. En algunas situaciones (la más común
ocurre en algoritmos matemáticos), un rango muy pequeño de
datos contenidos dentro de las fronteras de los datos válidos para
un programa pueden causar procesamiento extremo, e incluso
erróneo, o profunda degradación del rendimiento. La prueba de
sensibilidad intenta descubrir combinaciones de datos dentro de
clases de entrada válidas que puedan causar inestabilidad o
procesamiento inadecuado.
D. Prueba de Rendimiento
Para sistemas en tiempo real y sistemas embebidos, el software que
proporcione la función requerida, pero que no se adecue a los
requerimientos de rendimiento, es inaceptable. La prueba de
rendimiento se diseña para poner a prueba el rendimiento del
software en tiempo de corrida, dentro del contexto de un sistema
integrado. La prueba del rendimiento ocurre a lo largo de todos los
pasos del proceso de prueba. Incluso en el nivel de unidad, puede
accederse al rendimiento de un módulo individual conforme se
realizan las pruebas.

Sin embargo, no es sino hasta que todos los elementos del sistema
están plenamente integrados cuando puede determinarse el
verdadero rendimiento de un sistema.
Las pruebas de rendimiento con frecuencia se aparean con las
pruebas de esfuerzo y por lo general requieren instrumentación de
hardware y de software, es decir, con frecuencia es necesario medir
la utilización de los recursos (por ejemplo, ciclos del procesador) en
forma meticulosa.
La instrumentación externa puede monitorear intervalos de
ejecución y eventos de registro (por ejemplo, interrupciones)
conforme ocurren, y los muestreos del estado de la máquina de
manera regular. Con la instrumentación de un sistema, la persona
que realiza la prueba puede descubrir situaciones que conduzcan a
degradación y posibles fallas del sistema.
E. Pruebas de Despliegue
En muchos casos, el software debe ejecutarse en varias plataformas
y bajo más de un entorno de sistema operativo. La prueba de
despliegue, en ocasiones llamada prueba de configuración, ejercita
el software en cada entorno en el que debe operar. Además,
examina todos los procedimientos de instalación y el software de
instalación especializado (por ejemplo, “instaladores”) que usarán
los clientes, así como toda la documentación que se usará para
introducir el software a los usuarios finales.
Una prueba de despliegue más profunda puede abarcar
combinaciones de navegadores web con varios sistemas operativos
(por ejemplo, Linux, Mac OS, Windows). Puesto que la seguridad es
un tema principal, un juego completo de pruebas de seguridad se
integraría con la prueba de despliegue.

TESTING
TEMA: Diseño de Casos

de Prueba

Todo sistema o aplicación debe ser probado mediante su ejecución
controlada antes de ser entregado al cliente. Las pruebas
constituyen un método más para poder verificar y validar el
software.
Las pruebas presentan una interesante anomalía para los ingenieros
de software, quienes por naturaleza son personas constructivas. Las
pruebas requieren que el desarrollador deseche nociones
preconcebidas sobre lo “correcto” del software recién desarrollado
y luego trabajen duro para diseñar casos de prueba a fin de
“romper” el software.
FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE

La meta de probar es encontrar errores, y una buena prueba es
aquella que tiene una alta probabilidad de encontrar uno. Por
tanto, un sistema basado en computadora o un producto debe
diseñarse e implementarse teniendo en mente la
“comprobabilidad”. Al mismo tiempo, las pruebas en sí mismas
deben mostrar un conjunto de características que logren la meta de
encontrar la mayor cantidad de errores con el mínimo esfuerzo.
“La comprobabilidad del software significa simplemente saber con
cuánta facilidad puede probarse [un programa de cómputo].” Las
siguientes características conducen a software comprobable.
Operatividad. “Mientras mejor funcione, más eficientemente puede
probarse.” Si un sistema se diseña e implementa teniendo como
objetivo la calidad, relativamente pocos errores bloquearán la
ejecución de las pruebas, lo que permitirá avanzar en ellas sin
interrupciones.
Observabilidad. “Lo que ve es lo que prueba.” Las entradas
proporcionadas como parte de las pruebas producen distintas
salidas.

Controlabilidad. “Mientras mejor pueda controlar el software, más
podrá automatizar y optimizar las pruebas.” Todas las salidas
posibles pueden generarse a través de alguna combinación de
entradas, y los formatos de E/S son consistentes y estructurados.
Descomponibilidad. “Al controlar el ámbito de las pruebas, es
posible aislar más rápidamente los problemas y realizar pruebas
nuevas y más inteligentes.” El sistema de software se construye a
partir de módulos independientes que pueden probarse de manera
independiente.
Simplicidad. “Mientras haya menos que probar, más rápidamente
se le puede probar.” El programa debe mostrar simplicidad
funcional (por ejemplo, el conjunto característico es el mínimo
necesario para satisfacer los requerimientos); simplicidad
estructural (la arquitectura es modular para limitar la propagación
de fallos) y simplicidad de código (se adopta un estándar de
codificación para facilitar la inspección y el mantenimiento).
Estabilidad. “Mientras menos cambios, menos perturbaciones para
probar.” Los cambios al software son raros, se controlan cuando
ocurren y no invalidan las pruebas existentes. El software se
recupera bien de los fallos.
Comprensibilidad. “Mientras más información se tenga, se probará
con más inteligencia.” El diseño arquitectónico y las dependencias
entre componentes internos, externos y compartidos son bien
comprendidos. La documentación técnica es accesible al instante,
está bien organizada, es específica, detallada y precisa. Los cambios
al diseño son comunicados a los examinadores.
Pueden usarse estos atributos para desarrollar una configuración de

software (es decir, programas, datos y documentos) que sean
fáciles de probar.

Una buena prueba tiene una alta probabilidad de encontrar un
error. Para lograr esta meta, el examinador debe comprender el
software e intentar desarrollar una imagen mental de cómo puede
fallar. De manera ideal, se prueban las clases de fallas.
Por ejemplo, una clase de fallas potenciales en una interfaz gráfica
de usuario es la falla para reconocer la posición adecuada del ratón.
Se diseña entonces un conjunto de pruebas para revisar el ratón
con la intención de demostrar un error en el reconocimiento de la
posición del ratón.
Una buena prueba no es redundante. El tiempo y los recursos de la
prueba son limitados. No se trata de realizar una prueba que tenga
el mismo propósito que otra. Cada una debe tener un propósito
diferente (incluso si es sutilmente diferente).
Una buena prueba debe ser “la mejor de la camada”. En un grupo
de pruebas que tengan una intención similar, las limitaciones de
tiempo y recursos pueden mitigar la ejecución de sólo un
subconjunto de dichas pruebas. En tales casos, debe usarse la
prueba que tenga la mayor probabilidad de descubrir toda una
clase de errores.
Una buena prueba no debe ser demasiado simple o demasiado
compleja. Aunque en ocasiones es posible combinar una serie de
pruebas en un caso de prueba, los efectos colaterales posibles
asociados con este enfoque pueden enmascarar errores. En
general, cada prueba debe ejecutarse por separado.

La prueba exhaustiva del software es impracticable, no se pueden
probar todas las posibilidades de su funcionamiento incluso en
programas pequeños y sencillos. EL objetivo de las pruebas es la
detección de defectos en el software. Se trata de una actividad a
posteriori, de detección, y no de prevención, de problemas en el
software. Las pruebas permiten la rectificación en el software. El
descubrimiento de un defecto significa un éxito para la mejora de la
calidad.
La filosofía más adecuada consiste en planificarlas y diseñarlas de
forma sistemática para poder detectar el máximo número y
variedad de defectos con el mínimo consumo de esfuerzo y tiempo.
Pruebas exhaustivas
Considere un programa de 100 líneas en el lenguaje C. Después de
alguna declaración básica de datos, el programa contiene dos
bucles anidados que se ejecutan de 1 a 20 veces cada uno,
dependiendo de las condiciones especificadas en la entrada.
Dentro del bucle interior, se requieren cuatro constructores if-then-
else. ¡Existen aproximadamente 1014 rutas posibles que pueden
ejecutarse en este programa!
Para poner este número en perspectiva, suponga que se desarrolló
un procesador de prueba mágico (“mágico” porque no existe tal
procesador) para realizar pruebas exhaustivas. El procesador puede
desarrollar un caso de prueba, ejecutarlo y evaluar los resultados
en un milisegundo. Si trabajara 24 horas al día los 365 días del año,
el procesador trabajaría durante 3170 años para probar el
programa.
Esto, sin duda alguna, causaría estragos en la mayoría de los
calendarios de desarrollo.
Por tanto, es razonable afirmar que la prueba exhaustiva es
imposible para sistemas de software grandes.

Las técnicas de diseño de casos de prueba tienen como objetivo
conseguir una confianza aceptable en que se detectarán los
defectos existentes, sin necesidad de consumir una cantidad
excesiva de recursos. Hay que buscar un equilibrio entre la
disponibilidad de recursos y la confianza que aportan los casos de
prueba para descubrir los defectos existentes.
Ya que no se pueden probar todas las posibilidades de
funcionamiento del software, el diseño de pruebas consiste en
elegir algunas de ellas que se consideren representativas del resto.
La dificultad es saber elegir los casos que se deban ejecutar. Una
elección puramente aleatoria no proporciona demasiada confianza
en que se puedan detectar todos los defectos existentes.
Existen tres enfoques para el diseño de casos de prueba:

Enfoque estructural o de caja blanca: se centra en la estructura
interna del programa para elegir los casos de prueba. La prueba
ideal consistiría en probar todos los posibles caminos de ejecución
que puedan trazarse.
Enfoque funcional o de caja negra: se estudia la especificación de

las funciones, la entrada y la salida para derivar los casos. La prueba
ideal es probar todas las posibles entradas y salidas del programa.
Enfoque aleatorio: se utilizan modelos (estadísticos) que

representen las posibles entradas al programa para crear a partir de
ellos los casos de prueba.

El diseño de casos tiene que basarse en la elección de caminos
importantes que ofrezcan una seguridad aceptable en descubrir
defectos, se utilizan los criterios de cobertura lógica. Una
clasificación de éstos es, en función de menor a mayor seguridad:
Cobertura de sentencias: Se trata de generar los casos de prueba
necesarios que cada sentencia o instrucción del programa se
ejecute al menos una vez.
Cobertura de decisiones: Cada decisión tiene, por lo menos, un
resultado verdadero y, al menos una vez, uno falso. Una ejecución
de pruebas que cumple la cobertura de decisiones cumple la
anterior.
Cobertura de condiciones: Cada condición de cada decisión adopte
el valor verdadero al menos una vez y falso al menos una vez. No
podemos asegurar que si se cumple esta cobertura se cumpla
necesariamente la anterior.
Criterio de decisión/condición: Consiste en exigir el criterio de
cobertura de condiciones obligando a que se cumpla el criterio de
decisiones.
Criterio de condición múltiple: En el caso de que se considere que la
evaluación de las condiciones de cada decisión no se realiza de
forma simultánea, se descompone cada decisión multicondicional
en decisiones unicondicionales y se debe conseguir que todas las
posibles combinaciones de resultados de cada condición en cada
decisión se ejecute al menos una vez.
Cada uno de los posibles caminos del programa se debe ejecutar al
menos una vez. El camino de pruebas atraviesa como máximo una
vez el interior de cada bucle que se encuentra. Los bucles deberían
probarse al menos tres veces, una sin entrar en su interior, otra
ejecutándolo una vez y otra más ejecutándolo dos veces. Los bucles
constituyen el elemento de los programas que genera un mayor
número de problemas para la cobertura de caminos.

La prueba funcional o de caja negra se centra en el estudio de la
especificación del software, del análisis de las funciones que debe
realizar, de las entradas y de las salidas. La prueba exhaustiva de
caja negra es impracticable. Debemos buscar criterios que permitan
elegir un subconjunto de casos cuya ejecución aporte una cierta
confianza en detectar los posibles defectos del software. Un caso de
prueba está bien elegido sí:
Reduce el número de otros casos necesarios para que la prueba sea
razonable. Esto implica que el caso ejecute el máximo número de
posibilidades de entrada diferentes para así reducir el total de
casos.
Cubre un conjunto extenso de otros casos posibles, indica algo
acerca de la ausencia o la presencia de defectos en el conjunto
específico de entradas que prueba, así como de otros conjuntos
similares.
Particiones o clases de equivalencia
Las cualidades que definen un buen caso de prueba:
•Cada caso debe cubrir el máximo número de entradas.
•Debe tratarse el dominio de valores de entrada dividido en un
número finito de clases de equivalencia.
El método de diseño de casos consiste en:
•Identificación de clases de equivalencia:
Identificación de las condiciones de las entradas del programa.
Identificar las clases de equivalencia (datos válidos y datos no
válidos).
•Creación de los casos de prueba correspondientes:
Asignación de un número único a cada clase de equivalencia.
Hasta que todas las clases de equivalencia hayan sido cubiertas
por casos de prueba, se tratará de escribir un caso que cubra
tantas clases válidas no incorporadas como sea posible.
Hasta que todas las clases de equivalencia no válidas hayan sido
cubiertas por casos de prueba, escribir un caso para una única
clase no valida sin cubrir.
Análisis de Valores Límite (AVL)
Son casos de prueba que exploran las condiciones límite de un
programa. Las situaciones límite son las que se hallan arriba, abajo
y en los márgenes de las clases de equivalencia.
Se diferencian de las particiones de equivalencia en que:
•Se requiere la selección de uno o más elementos de manera que
los márgenes se sometan a prueba.
•Consideran también el espacio de salida.
Conjetura de errores
Se enumera una lisa de equivocaciones que pueden cometer los
desarrolladores y de las situaciones propensas a ciertos errores.
Después se generan casos de prueba en base a dicha lista.
Casos que se pueden presentar:
•El valor cero es una situación propensa a errores.
•Si se han de introducir un número variable de valores, probar el
caso de no introducir ninguno.
•Suponer que el programador pudiera haber interpretado algo mal
en la especificación.

Simulamos la entrada habitual del programa creando datos de
entrada en la secuencia y con la frecuencia con la que podrían
aparecer en la práctica, de forma continua sin parar.
Indicando la distribución estadística que siguen las entradas,
hacemos que la frecuencia de las entradas sea la apropiada para
orientar las pruebas hacia lo que es probable que suceda en la
práctica.

La documentación es necesaria para una buena organización de las
pruebas, así como para asegurar su reutilización, que es
fundamental para optimizar la eficacia como la eficiencia de las
pruebas.
Plan de pruebas
Su objetivo es señalar el enfoque, los recursos y el esquema de las
actividades de prueba, así como los elementos a probar,
características, personal responsable y los riesgos asociados.
Especificación del diseño de pruebas

Su objetivo es especificar los refinamientos necesarios sobre el
enfoque general reflejado en el plan e identificar las características
que se deben probar con este diseño de pruebas.
Especificación de casos de pruebas

El objetivo es definir uno de los casos de prueba identificado por
una especificación del diseño de las pruebas.
Especificación del procedimiento de prueba

El objetivo es especificar los pasos para la ejecución de un conjunto
de casos de prueba o los pasos utilizados para analizar un elemento
software con el propósito de evaluar un conjunto de características
del mismo.

El proceso de pruebas consta de las siguientes fases:
1. Ejecutar las pruebas:
Ejecutar las pruebas.
Comprobar si ha habido algún fallo en la ejecución.
En caso de fallo, pasar a depuración o corrección del código.
Ejecutar las nuevas pruebas corregidas.
Si no hay fallos, pasar a la comprobación de la terminación de
las pruebas.
2. Comprobar si se ha concluido el proceso de prueba:
Tras la ejecución, comprobar si se cumplen los criterios de
completitud de pruebas descritos en el plan de pruebas.
En caso de terminar las pruebas, pasar a la evaluación de los
productos probados sobre la base de los resultados obtenidos.
En caso de no terminar las pruebas, comprobar la presencia de
condiciones anormales en la prueba.
Si se dan condiciones anormales, se pasa de nuevo a la
evaluación, en caso contrario, se pasa a generar y ejecutar
pruebas adicionales.
3. En caso de que hayan terminado, evaluar los resultados. En caso
contrario, generar pruebas adicionales.
Documentación de la ejecución de pruebas

Se pueden distinguir dos grupos principales de documentos:
1. Documentación de entrada, constituida por las especificaciones
de los casos de prueba que se van a usar y las especificaciones de
los procedimientos de pruebas.
2. Documentación de salida o informes sobre la ejecución. Cada
ejecución de pruebas generará dos tipos de documentos:
•Histórico de pruebas o registro cronológico de la ejecución.
•Informe de los incidentes ocurridos durante la ejecución.

Histórico de pruebas
El objetivo es la documentación de todos los hechos relevantes
ocurridos durante la ejecución de las pruebas.
Informe de incidente
Su objetivo es documentar cada incidente ocurrido en la prueba y
que requiera una posterior investigación.
Informe resumen de las pruebas

El objetivo es resumir los resultados de las actividades de prueba y
aporta una evaluación del software basada en dichos resultados.
Depuración
Es el proceso de localizar, analizar y corregir los defectos que se
sospecha que contiene el software. Suele ser consecuencia de una
prueba con éxito. Las consecuencias de la depuración pueden ser:
•Encontrar la causa del error, analizarla y corregirla.
•No encontrar la causa y, por tanto, tener que generar nuevos casos
de prueba.
Las dos principales etapas en la depuración son:

•Localización del defecto, que conlleva la mayor parte del esfuerzo.
•Corrección del defecto, efectuando las modificaciones necesarias
en el software.
Análisis de errores o análisis causal

El objetivo es proporcionar información sobre la naturaleza de los
defectos, con el fin de informar al personal sobre los errores que
comete para que se puedan prevenir en el futuro.

Dada la definición de prueba, el paso siguiente es determinar si es
posible probar un programa para encontrar todos sus errores. En
general, no es práctico y más aún es imposible encontrar todos los
errores en un programa.
Es decir hay imposibilidad de una prueba “completa”.
El diseño de pruebas para el software o para otros productos de
ingeniería puede requerir tanto esfuerzo como el propio diseño
inicial del producto.
Sin embargo los ingenieros de software tratan las pruebas como
algo sin importancia, desarrollando casos de prueba que “parezcan
adecuados” pero que tienen poca garantía de ser completos.
“Existe una sola regla para el diseño de casos de prueba: cubrir
todas las posibilidades, sin hacer demasiados casos de prueba”
[Tsuneo Yamaura].
Para realizar la verificación de un producto, el especialista diseña un

conjunto de datos con los que realiza la prueba funcional.
La prueba funcional determina si la función que especifica un
producto coincide con las funciones implementadas en ese
producto.
Cualquier producto de ingeniería puede probarse de una de estas
dos formas: (1) conociendo la función específica para la que fue
diseñado el producto, se pueden llevar a cabo pruebas que
demuestren que cada función es completamente operativa y, al
mismo tiempo, buscando errores en cada función; (2) conociendo
el funcionamiento del producto, se pueden desarrollar pruebas que
aseguren que “todas las piezas encajen”, o sea, que la operación
interna se ajusta a las especificaciones y que todos los
componentes internos se han comprobado de forma adecuada. El
primer enfoque de prueba se denomina prueba de caja negra y el
segundo, prueba de caja blanca.

Cuando se considera el software de computadora, la prueba de caja
negra se refiere a las pruebas que se llevan a cabo sobre la interfaz
del software. O sea, los casos de prueba pretenden demostrar que
las funciones del software son operativas, que la entrada se acepta
de forma adecuada y que se produce un resultado correcto, así
como que la integridad de la información externa se mantiene. Una
prueba de caja negra examina algunos aspectos del modelo
fundamental del sistema sin tener mucho en cuenta la estructura
lógica interna del software.
La prueba de caja blanca del software se basa en el minucioso
examen de los detalles procedimentales. Se comprueban los
caminos lógicos del software proponiendo casos de prueba que
ejerciten conjuntos específicos de condiciones y/o bucles. Lo que se
tiene que hacer es definir todos los caminos lógicos, desarrollar
casos de prueba que los ejerciten y evaluar los resultados, es decir,
generar casos de prueba que ejerciten exhaustivamente la lógica
del programa. Sin embargo la prueba exhaustiva presenta ciertos
problemas logísticos. Incluso para pequeños programas, el número
de caminos lógicos posibles puede ser enorme. Sin embargo la
prueba de caja blanca no se debe desechar como impracticable. Se
pueden elegir y ejercitar una serie de caminos lógicos importantes.
Se pueden comprobar las estructuras de datos más importantes
para verificar su validez. Se pueden combinar los atributos de la
prueba de caja blanca así como los de caja negra, para llegar a un
método que valide la interfaz del software y asegure
selectivamente que el funcionamiento interno del software es
correcto.

CAJA BLANCA
También llamadas lógicas, pretenden examinar la estructura interna
del programa; es por eso que se llaman blanca o de cristal porque
permiten ver el interior del programa. Es un método de diseño de
casos de prueba que usa la estructura de control del diseño
procedimental para obtener los casos de prueba. Mediante los
métodos de casos de prueba de caja blanca, el ingeniero de
software puede obtener casos de prueba que (1) garanticen que se
ejercita por lo menos una vez todos los caminos independientes de
cada módulo; (2) ejerciten todas las decisiones lógicas en sus
vertientes verdadera y falsa; (3) ejecuten todos los bucles en sus
límites y con sus límites operacionales; y (4) ejerciten las
estructuras internas de datos para asegurar su validez.
CAJA NEGRA
Intentan examinar el comportamiento del programa basándose en
las especificaciones de las funciones que debe realizar; por lo que
se llaman pruebas del comportamiento y se centran en los
requisitos funcionales del software. O sea, la prueba de caja negra
permite al ingeniero de software obtener conjuntos de condiciones
de entrada que ejerciten completamente todos los requisitos
funcionales del programa.
Aquí no importa ver cómo es el interior del programa, ya que se lo
considera una caja negra que no permite la visión de la estructura
interna.
La prueba de caja negra intenta encontrar errores de las siguientes
categorías: (1) funciones incorrectas o ausentes; (2) errores de
interfaz; (3) errores de estructura de datos o en accesos a bases de
datos externas; (4) errores de rendimiento y (5) errores de
inicialización y de terminación.

Llamada también cobertura lógica o pruebas basadas en la
estructura.
Se ocupa del grado en que los casos de prueba ejercitan o cubren la
lógica (código fuente) del programa.
Consiste en recorrer todas las posibles secuencias de

sentencias.
La prueba perfecta de caja blanca es aquella en que se recorre cada

uno de los posibles caminos lógicos en un programa, pero desde el
momento en que esto es casi imposible de realizar en un programa
con lazos, la prueba completa de secuencias no se considera aquí
como una meta posible de lograr.
La prueba exhaustiva es impracticable hasta en programas
pequeños, es decir completa al 100%.
Por ejemplo, un programa Fortran con 50 líneas y 25 sentencias IF
en serie contiene 33,5 millones de sentencias potenciales (2
posibles salidas: Verdadero y Falso, en 25 sentencias es igual a 225
potenciales secuencias).
Esta no es una razón para desechar este tipo de técnicas ya que
pueden probarse ciertos caminos o secuencias lógicas importantes,
seleccionadas según un criterio de cobertura lógica, que ofrezcan
una seguridad aceptable en el descubrimiento de errores.
Criterios:
1) Cobertura de sentencias
2) Cobertura de decisión o de ramificación
3) Cobertura de condición
4) Cobertura de decisión/condición

La complejidad ciclomática es una medición de software que
proporciona una evaluación cuantitativa de la complejidad lógica de
un programa. Cuando se usa en el contexto del método de prueba
de la ruta básica, el valor calculado por la complejidad ciclomática
define el número de rutas independientes del conjunto básico de
un programa y le brinda una cota superior para el número de
pruebas que debe realizar a fin de asegurar que todos los
enunciados se ejecutaron al menos una vez.
La complejidad ciclomática tiene fundamentos en la teoría de
gráficos y proporciona una medición de software extremadamente
útil. La complejidad se calcula en una de tres formas:
1. El número de regiones del gráfico de flujo corresponde a la
complejidad ciclomática.
2. La complejidad ciclomática V(G) para un gráfico de flujo G se
define como V(G) = E - N + 2
donde E es el número de aristas del gráfico de flujo y N el número
de nodos del gráfico de flujo.
3. La complejidad ciclomática V(G) para un gráfico de flujo G
también se define como V(G) = P + 1
donde P es el número de nodos predicado contenidos en el gráfico
de flujo G.
a) Diagrama de Flujo b) Gráfico de Flujo

En el gráfico de flujo de la figura anterior, la complejidad ciclomática
puede calcularse usando cada uno de los algoritmos recién
indicados:
1. El gráfico de flujo tiene cuatro regiones.
2. V(G) = 11 aristas - 9 nodos + 2 = 4.
3. V(G) = 3 nodos predicado + 1 = 4.
Por tanto, la complejidad ciclomática del gráfico de flujo en la figura
anterior es 4.
Más importante, el valor para V(G) proporciona una cota superior
para el número de rutas independientes que forman el conjunto
básico y, por implicación, una cota superior sobre el número de
pruebas que deben diseñarse y ejecutarse para garantizar cobertura
de todos los enunciados del programa.

Llamada también prueba producida por los datos o prueba
producida por entrada/salida.
Aquí se considera el programa como una caja negra, es decir se
desentiende del comportamiento y estructura interna del
programa.
Su interés se dirige a encontrar circunstancias en las cuáles el
programa no se comporta de acuerdo a sus especificaciones.
Los datos de prueba se preparan de acuerdo a las especificaciones.
Para detectar errores de este tipo habría que usar no solamente los
datos de entrada válidos sino también todos los datos de entrada
posibles. Esto demuestra que la prueba exhaustiva de entrada es
imposible e impracticable.
Ejemplo: Sumar 2 enteros A y B, de dos dígitos cada uno y cualquier
signo implica 40.000 casos. Es decir que hay que considerar (199 x
199) porqué hay que considerar todas las combinaciones de A y B
ya que el programa es una caja negra.
Debe buscarse el subconjunto de casos con mayor probabilidad de
encontrar errores (es decir una prueba razonablemente rigurosa).
Las propiedades de un caso bien elegido (para formar el
mencionado subconjunto) son:
•Reduce el número de otros casos, eso implica que el caso invoque
el máximo número de condiciones de entrada diferentes para
minimizar el número total de casos.
•Cubre un conjunto extenso de otros casos posibles, dice algo
acerca de la ausencia o presencia de errores con respecto al
conjunto específico de valores de entrada y también de otros.
Las técnicas de caja negra de mayor aplicación son:

•Particiones de equivalencia.
•Análisis de Valores Límites (AVL).
•Conjetura de errores.

Se basa en las dos propiedades consideradas para definir un caso
de prueba bien elegido. Esto es:
a) Cada caso debe invocar el mayor número posible de condiciones
de entrada diferentes a fin de minimizar el número total de casos
necesarios.
b) Debe tratarse de partir el dominio de entrada en un número
finito de “clases de equivalencia”, en las que las pruebas de un valor
representativo de cada clase sea equivalente a la prueba de
cualquier valor.
Es decir que si un caso de prueba perteneciente a una clase de
equivalencia detecta un error, se espera que cualquier otro caso de
prueba perteneciente a la misma clase detecte el mismo error.
Estas consideraciones forman una metodología de caja negra que
se conoce como “partición de equivalencia”.
Etapas:
El proyecto de caso de prueba por medio de partición de
equivalencia se realiza en dos pasos:
•Identificación de la clase de equivalencia.
•Definición de los casos de prueba.
Identificación de las clases de equivalencia

Las clases de equivalencia se identifican tomando cada condición de
entrada (usualmente sacada de la especificación) y dividiéndola en
dos o más grupos.
Para ello se emplea la siguiente tabla:

Se identifican dos tipos de clases:
Clases de equivalencia válidas (que representan entradas válidas al
programa).
Clases de equivalencias inválidas (que representan todos los otros
estados posibles de la condición, valores erróneos de entrada).
Se puede recurrir a la tabla anterior o bien a una enumeración en
formato de un perfil como:
Introducir un número entre 1 y 99
a.1) Casos Válidos
a.1.1) Un Nº entre 1 y 99
b.1) Casos Inválidos
b.1.1) El cero (0)
b.1.2) Un Nº > 99
b.1.3) Nº Negativos
b.1.4) Letras y otros símbolos no numéricos
Pautas para la definición de clases

Si la condición de entrada especifica:
1) Para un “rango” de valores se debe especificar una clase válida y
dos clases inválidas.
Por ejemplo: Válida 1<= nº <= 99
Inválidas nº < 1 ; nº > 99
2) Para un “número” de valores se debe especificar una clase válida

y dos inválidas.
Por ejemplo: “podrán ser matriculados de 1 a 6 propietarios por
automóvil”
Una Clase Válida: 1 <= nº propietarios <= 6
Dos clases Inválidas: nº propietarios < 1 ; nº propietarios > 6

Ejemplo: transacción bancaria.
Especificación:
Código de área: número de 3 dígitos que no empieza ni por 0 ni por
1.
Palabra clave: valor alfanumérico de 6 dígitos.
Ordenes posibles: “cheque”, “depósito”, “pago factura”, “retiro de
fondos”, etc.
Aplicación de reglas:
+ Código: número, booleana
- clase válida (número).
- clase inválida (no es número).
La clase número puede subdividirse por rango y
obtenemos:
- subclase válida (200 <= código <= 999).
- 2 subclases inválidas (código < 200 y código > 999).
+ Palabra clave: número específico de valores
- clase válida (6 caracteres).
- dos clases inválidas (más de 6 y menos de 6).
+ Orden: conjunto de valores
- una clase válida para cada orden (“depósito”, “cheque”,
etc., 4 en total).
- una clase inválida (“divisas” por ejemplo).
En la siguiente figura se enumeran las clases mediante una tabla y

la generación de los casos de prueba (suponiendo que el orden de
ingreso de los datos es código, nombre y orden).

Casos Válidos
300 Nómina Depósito (1) (5) (9)
400 Viajes Cheque (1) (5) (8)
500 Coches Pago factura (1) (5) (10)
600 Comida Retiro de fondos (1) (5) (11)
Casos Inválidos
180 (2)
1032 (3)
xy (4)
350 [CR] (1) (6)
450 Regalos (1) (7)
550 Casada (1) (5) (12)

Es una técnica complementaria a la Técnica de Partición de
Equivalencias. La experiencia muestra que los casos de prueba que
exploran condiciones límites o de frontera producen mejores
resultados que aquellos que no lo hacen.
Las condiciones límite son las situaciones que se hallan
directamente arriba y debajo de los márgenes de las clases de
equivalencia de entrada y de salida.
Por ejemplo, las desigualdades tales como < en vez de <= suelen
causar fallos.
Esta es una técnica de diseño que complementa a la de particiones
de equivalencia. Las diferencias son:
Más que elegir “cualquier caso” como representativo de una clase
de equivalencia, se requiere la selección de uno o más elementos
tal que los márgenes se sometan a prueba.
Más que concentrarse en el dominio de la entrada (condiciones de
entrada), los casos de prueba se generan considerando también el
espacio de salida.
Reglas generales
Si la condición de entrada especifica un rango de valores (-1.0 <=
valor <= 1.0), escribir casos de prueba para los extremos del rango y
casos inválidos para situaciones justo más allá de los extremos.
Casos: -1.0, +1.0, -1.001 y +1.001
Si la condición de entrada especifica un número de valores, escribir
casos de prueba para los números de valores máximo y mínimo y
uno más del máximo y uno menos de mínimo.
Casos: si un archivo de entrada puede contener de 1 a 255
registros, escribir casos para 0, 1, 255 y 256.
Por ejemplo usar la regla 1) para cada condición de salida.

Si el descuento máximo aplicable en compra de contado será del
50%, el mínimo será el 6%, etc. Se escribirán casos para obtener
descuentos del 5,99%, 6%, 50% y 50,1%.

La idea básica es enumerar una lista de errores posibles o de
situaciones propensas a ciertos errores y generar casos de prueba
en base a esta lista (suelen corresponderse con errores que
aparecen comúnmente y no con aspectos funcionales).
Esta técnica también se ha denominado generación de casos o
valores especiales, no obtenidos en base a otros métodos sino
mediante la intuición o la experiencia.
No existen directivas eficaces que puedan ayudar a proporcionar
algunos ejemplos que reflejen el espíritu adecuado para desarrollar
estos casos, la técnica se basa en la intuición de dichos casos
especiales.
Ejemplos:
El valor 0 es una situación propensa a error tanto en la entrada
como en la salida.
En situaciones en las que se mete un número variable de valores
(por ejemplo una lista), el caso de introducir ningún valor y un solo
valor (también todos los valores iguales, etc.)
Poder imaginar que el programador pudiera haber mal interpretado
algo en la especificación dada por el analista.
Poder imaginar lo que el usuario puede introducir como entrada a
un programa (se dice que debe preveerse toda clase de acciones de
un usuario como si fuera “completamente tonto” o, incluso, si
quisiera sabotear).

LA EVALUACIÓN
TEMA: Evaluación,
medición y métricas

Hoy en día la calidad es un término que preocupa a las empresas
productoras de software y que debe tenerse en cuenta en todas las
etapas del desarrollo del mismo. Independientemente del tipo de
producto que se esté desarrollando, la calidad es fundamental para
lograr la satisfacción de las necesidades y expectativas del cliente.
Las métricas de software proporcionan información objetiva que
contribuye al mejoramiento de los procesos y productos de
software, lo cual evidentemente favorece al logro de la calidad.
En la actualidad, el uso de las métricas se está poniendo en práctica

con éxito en el amplio mercado del software pues las empresas
productoras están reconociendo la importancia que tienen las
mediciones para cuantificar y por consiguiente gestionar de forma
más efectiva la calidad de los procesos y productos de software. En
empresas que se dedican exclusivamente a la informática, se tiene
noción de la necesidad de formalizar los mecanismos de
estimación, comprendiendo que los registros históricos de antiguos
proyectos realizados pueden ayudar a estimar con mayor exactitud
el esfuerzo, tiempo de desarrollo, costo, posibles errores, recursos y
tamaño para los nuevos proyectos. Es válido aclarar que en
ocasiones los resultados de los procesos de medición no son
interpretados de la mejor manera, pues aún existen compañías que
no tienen una cultura adecuada sobre la medición, desconociendo
el alcance de madurez y calidad que pudiera alcanzar el producto
final.
Lord Kelvin dijo alguna vez:
Cuando puedes medir aquello de lo que hablas y expresarlo en
números, sabes algo acerca de ello; pero cuando no puedes medir,
cuando no puedes expresarlo en números, tu conocimiento es
exiguo e insatisfactorio: puede ser el comienzo del conocimiento;
sin embargo, apenas habrás avanzado, en tus pensamientos, hacia
la etapa de una ciencia.

Para evaluar la calidad del software, primero hay que establecer los
requisitos de la evaluación, para luego especificar, diseñar y
ejecutar la evaluación.
Para establecer requisitos y objetivos se deben completar cuatro
tareas fundamentales: Establecer el propósito de la evaluación.
Identificar el producto a evaluar, Identificar los requerimientos de
calidad y Elegir el marco de calidad.
Establecer el Propósito de la Evaluación: Según la Norma IRAM: “El
propósito de la evaluación de la calidad del software es apoyar
directamente tanto el desarrollo como la adquisición de un
software que satisfaga las necesidades del usuario y del cliente. El
objetivo final es asegurarse de que el producto proporciona la
calidad requerida, que satisface las necesidades explícitas e
implícitas de los usuarios (incluyendo a los operadores, a los
receptores de los resultados del software, o al personal de
mantenimiento del software)”.
En sentido general, el propósito de la evaluación de la calidad
puede ser:
• Aceptar o rechazar un producto de software desarrollado o
comprado.
• Predecir o estimar la calidad de dicho producto.
• Comparar un producto con los productos competidores.
• Seleccionar un producto entre productos alternativos.
• Decidir cuándo mejorar o sustituir un producto.
Identificar el Producto a Evaluar: Se debe identificar claramente el
producto a evaluar, o la parte del producto sujeto a evaluación. Así,
tenemos cuatro posibles escenarios:
1. En Desarrollo: Para pasar a la siguiente etapa de desarrollo. Aquí
tienen impacto los artefactos y los módulos existentes, tanto como
sus relaciones con el Plan de Proyecto de Desarrollo del Software.
Estos pueden cambiar y actualizarse en tanto se avanza en el
desarrollo de la aplicación.

2. Desarrollado: Para estimar su calidad final. Se debe identificar
todos los artefactos y los módulos existentes relativos al software o
al módulo bajo estudio.
3. Desarrollado: Cuando queda obsoleto o cuando se lanza una
actualización.
4. Evaluación y selección de un software entre productos
alternativos: los productos a evaluar son productos finales de
software o componentes, ya sean construidos a medida,
prefabricados o incluso prototipos.
En cualquiera de los casos, si no es posible identificar en detalle, es
necesario documentar inicialmente una lista de los aspectos
conocidos, que luego se irá refinando.
Identificar los requerimientos de calidad: En esta etapa, hay una
serie de definiciones que hay que realizar:
• En función del Stakeholder “Factor que encarga la evaluación”, se
debe identificar cuáles serán los demás Stakeholders: Evaluador,
Factor normativo, Inversor en el desarrollo, Sponsor, Usuario,
Empresa del usuario, Otras empresas, Ingeniero de requerimientos,
Analista de sistemas, Diseñador del software, Programador,
Gerente de Proyecto, Tester, Analista QA.
• Se debe especificar cuáles son los Requerimientos de Calidad
para el Producto Software, usando para ello, algunos de los
Modelos de Calidad existentes.
Elegir el Marco de Calidad: Para lograr definir el marco de calidad,
se cuenta con dos tareas fundamentales:
1. Definir el Modelo de Calidad a usar: En función de lo
especificado en Identificar los Requerimiento de Calidad, se debe
especificar el Modelo de Calidad a utilizar para la Evaluación.
2. Definir la rigurosidad del modelo: Se usará el modelo en el cual
los parámetros de ponderación, las rigurosidades y las fidelidades
serán todas idénticas a los pesos relativos obtenidos de los
cuestionarios por la característica básica que de ella derivan.

Todas las organizaciones de software exitosas implementan
mediciones como parte de sus actividades cotidianas pues estas
brindan la información objetiva necesaria para la toma de
decisiones y que tendrá un impacto efectivo en el negocio y
desempeño en la ingeniería.
Para poder asegurar que un proceso o sus productos resultantes
son de calidad o poder compararlos, es necesario asignar valores,
descriptores, indicadores o algún otro mecanismo mediante el cual
se pueda llevar a cabo dicha comparación.
Para entender mejor el concepto de métrica es necesario aclarar
que los términos, métricas, medición y medida no tienen el mismo
significado.
Medida: Proporciona una indicación cuantitativa de la extensión,
cantidad, dimensiones, capacidad o tamaño de algunos atributos de
un proceso o producto.
Medición: La medición es el acto de determinar una medida.
Métrica: Es una medida cuantitativa del grado en que un sistema,
componente o proceso posee un atributo dado.
Se definen las métricas de software como “La aplicación continua
de mediciones basadas en técnicas para el proceso de desarrollo
del software y sus productos, para suministrar información
relevante a tiempo, así el administrador junto con el empleo de
estás técnicas mejorará el proceso y sus productos” .
Para una definición más completa debe incluirse los servicios
relacionados al software como la respuesta a los resultados del
cliente: Ver Fig. 1.
Figura 1. Concepto de Métricas.

Características de las Métricas
Para que sea útil en el contexto del mundo real, una métrica del
software debe ser objetiva, simple y calculable, consistente en el
empleo de unidades y tamaños, persuasiva, además debería ser
independiente del lenguaje de programación y proporcionar una
realimentación eficaz para el desarrollador de software.
¿Por qué se debe asegurar que las métricas cumplan estas
condiciones?:
Las métricas deben ser un instrumento que ayude a mejorar el
proceso, producto o proyecto de software, no tiene mucho sentido
aplicar métricas que lejos de ayudar a los desarrolladores
constituyan un problema; bien por ser demasiado complejas, o
porque no se entienden correctamente los objetivos que persiguen
o porque arrojen resultados imprecisos que no puedan ser
interpretados por los ingenieros de software.
Es importante entonces que una métrica pueda obtenerse
fácilmente, que se entienda por qué y para qué se utiliza, que los
cálculos no produzcan resultados ambiguos o en los que existan
extrañas combinaciones de unidades, y que la interpretación de
valores obtenidos esté acorde a las nociones intuitivas del ingeniero
de software. Por otra parte las métricas no deben ser específicas
para ningún lenguaje de programación o metodología de desarrollo.
Proceso de Medición
Todo proceso de medición del software tiene como objetivo
fundamental satisfacer necesidades de información a partir de las
cuales se deben identificar las entidades y los atributos que deben
ser medidos.
El proceso de medición, se caracteriza en cinco actividades:
Formulación: Obtención de medidas y métricas del software
apropiadas para la presentación del software en cuestión.

Colección: Mecanismo empleado para acumular datos necesarios
para obtener las métricas formuladas.
Análisis: Cálculo de las métricas y la aplicación de herramientas
matemáticas.
Interpretación: La evaluación de los resultados de las métricas en
un esfuerzo por conseguir una visión interna de la calidad de la
presentación.
Retroalimentación: Recomendaciones obtenidas de la
interpretación de métricas y técnicas transmitidas al equipo de
desarrollo de software.
Clasificación de las Métricas

Existen innumerables métricas con propósitos diferentes que
reflejan o describen la conducta del software, estas pueden medir
entre otros aspectos la competencia, calidad, desempeño y la
complejidad del software contribuyendo a establecer de una
manera sistemática y objetiva una visión interna del trabajo
mejorando así la calidad del producto.
A continuación se detalla una clasificación de las mismas:
Métricas de complejidad: Son todas las métricas de software que
definen de una u otra forma la medición de la complejidad. Tales
como volumen, tamaño, anidaciones, costo (estimación) y
configuración. Estas son los puntos críticos de la concepción,
viabilidad, análisis y diseño de software.
Métricas de calidad: Son todas las métricas de software que definen
de una u otra forma la calidad del software; tales como exactitud,
estructuración o modularidad, pruebas, mantenimiento,
reusabilidad, entre otras. Estas son los puntos críticos en el diseño,
codificación, pruebas y mantenimiento.

Métricas de competencia: Son todas las métricas que intentan
valorar o medir las actividades de productividad de los
programadores o practicantes con respecto a su certeza, rapidez,
eficiencia y competencia.
Métricas de desempeño: Corresponden a las métricas que miden la
conducta de módulos y sistemas de un software, bajo la supervisión
del sistema operativo o hardware. Generalmente tienen que ver
con la eficiencia de ejecución, tiempo, almacenamiento,
complejidad de algoritmos computacionales, etc.
Métricas estilizadas: Son las métricas de experimentación y de
preferencia. Por ejemplo: estilo de código, las convenciones de
datos, las limitaciones, etc. Pero estas no se deben confundir con
las métricas de calidad o complejidad.
Variedad de métricas: Tales como portabilidad, facilidad de
localización, consistencia, etc.
Estas clasificaciones de métricas fortalecen la idea de que más de
una métrica puede ser deseable para valorar la complejidad y la
calidad del software, teniendo en cuenta que para ello es necesario
medir los atributos del software.
Establecimiento de una línea base

Un punto de partida para realizar estimaciones es establecer una
línea base de métricas que permita a una organización sintonizar su
proceso de ingeniería del software para eliminar las causas de los
defectos que tienen el mayor impacto en el desarrollo del software,
es fundamental que una línea base contenga datos recopilados de
proyectos desarrollados anteriormente lo que requiere una
investigación histórica de los mismos; la línea base no es más que la
recopilación de medidas, métricas e indicadores que guíen el
proyecto o el proceso. Ver Fig. 2

Figura 2. Proceso de recopilación de métricas del Software.
Por lo general la información reunida no necesariamente tiene que

ser diferente. Las mismas métricas pueden obtener beneficios a
nivel de proceso, proyecto y producto.
Métricas del Proceso

Las métricas del proceso se recopilan de todos los proyectos y
durante un largo período de tiempo. Su intento es proporcionar
indicadores que lleven a mejoras de los procesos de software a
largo plazo. Un indicador es una métrica o una combinación de
métricas que proporcionan una visión profunda del proceso del
software, del proyecto de software o del producto en si.
La medición del proceso implica las mediciones de las actividades
relacionadas con el software siendo algunos de sus atributos típicos
el esfuerzo, el costo y los defectos encontrados. Las métricas
permiten tener una visión profunda del proceso de software que
ayudará a tomar decisiones más fundamentadas, ayudan a analizar
el trabajo desarrollado, conocer si se ha mejorado o no con
respecto a proyectos anteriores, ayudan a detectar áreas con
problemas para poder remediarlos a tiempo y a realizar mejores
estimaciones.
Para mejorar un proceso se deben medir los atributos del mismo,
desarrollar métricas de acuerdo a estos atributos y utilizarlas para
proporcionar indicadores que conduzcan la mejora del proceso. Los
errores detectados antes de la entrega del software, la
productividad, recursos y tiempo consumido y ajuste con la
planificación son algunos de los resultados que pueden medirse en
el proceso, así como las tareas específicas de la ingeniería del
software.
Actualmente existen diversas métricas, y éstas deben usarse
conforme se ajusten al proceso.
Las métricas del proceso se caracterizan por:
• El control y ejecución del proyecto.
• Medición de tiempos del análisis, diseño, implementación,
implantación y postimplantación.
• Medición de las pruebas (errores, cubrimiento, resultado en
número de defectos y número de éxitos).
• Medición de la transformación o evolución del producto.
¿Por qué el proceso?

Como se observa en la Fig. 3, existen varios factores que
determinan la calidad del software y la eficiencia de la organización,
entre ellos están la complejidad del producto, la tecnología (es
decir, los métodos y herramientas de la ingeniería del software) y
las personas (su habilidad y motivación), así como algunas
condiciones de entorno que también tienen su impacto, estas
pueden ser condiciones de gestión (Ej.: plazo de entrega, reglas
empresariales), entornos de desarrollo (Ej. herramientas de
software integradas) y características del cliente (Ej. facilidad de
comunicación y colaboración); sin embargo en el centro de todas
ellas se encuentra el proceso pues es el único factor de los
controlables al mejorar la calidad del software y su rendimiento
como organización. Analizando y mejorando el proceso se puede
obtener mejores productos.
Figura 3. Determinantes de la calidad del software y de la efectividad de la organización.
La eficacia de un proceso de software sólo puede medirse de

manera indirecta. Esto significa que es posible derivar un conjunto
de métricas con base en los resultados que pueden derivarse del
proceso. Los resultados incluyen medidas de los errores
descubiertos antes de liberar el software, defectos entregados a y
reportados por usuarios finales, productos operativos entregados
(productividad), esfuerzo humano empleado, tiempo calendario
consumido, conformidad con la agenda y otras medidas. También
pueden derivarse métricas de proceso al medir las características
de tareas de ingeniería de software específicas. Por ejemplo, puede
medirse el esfuerzo y el tiempo empleados al realizar las
actividades sombrilla y las actividades genéricas de ingeniería del
software.

Dado que el proyecto engloba todos los recursos, actividades y
artefactos, que se organizan para lograr un producto de software es
de vital importancia definir algunas mediciones que ayuden al
mejoramiento del mismo. A nivel de proyecto se minimiza la
planificación de desarrollo haciendo los ajustes necesarios para
evitar retrasos o riesgos potenciales, minimizar los defectos, y por
tanto la cantidad de trabajo que ha de rehacerse, lo que ocasiona
una reducción del coste global del proyecto, además puede
evaluarse la calidad de los productos en el momento actual y
cuando sea necesario.
La primera aplicación de métricas de proyectos en la mayoría de los
proyectos de software ocurre durante la estimación. Las métricas
recopiladas de proyectos anteriores se utilizan como una base
desde la que se realizan las estimaciones del esfuerzo y del tiempo
para el actual trabajo del software. A medida que avanza un
proyecto, las medidas del esfuerzo y del tiempo consumido se
comparan con las estimaciones originales (y la planificación de
proyectos). El gestor de proyectos utiliza estos datos para
supervisar y controlar el avance. A medida que comienza el trabajo
técnico, otras métricas de proyectos comienzan a tener significado.
Se miden los índices de producción representados mediante
páginas de documentación, las horas de revisión, los puntos de
función y las líneas fuentes entregadas, en el proyecto se sigue la
pista de los errores detectados durante todas las tareas de
ingeniería del software. Cuando va evolucionando el software
desde la especificación del diseño, se recopilan las métricas técnicas
para evaluar la calidad del mismo y para proporcionar indicadores
que influirán en el enfoque tomado para la generación y prueba del
código.

Finalmente los indicadores de proyecto permiten:
• Evaluar el estado del proyecto en curso.
• Seguir la pista de los riesgos potenciales.
• Detectar las áreas de problemas antes de que se conviertan en
“críticas”.
• Ajustar el flujo y las tareas del trabajo.
• Evaluar la habilidad del equipo del proyecto en controlar la
calidad de los productos de trabajo del software.
La intención de las métricas de proyecto es doble. Primero, se usan

para minimizar el calendario de desarrollo al hacer los ajustes
necesarios para evitar demoras y mitigar potenciales problemas y
riesgos. Segundo, se usan para valorar la calidad del producto sobre
una base en marcha y, cuando es necesario, modificar el enfoque
técnico para mejorar la calidad.
Conforme la calidad mejora, los defectos se minimizan, y conforme
el conteo de defectos baja, la cantidad de reelaboración requerida
durante el proyecto también se reduce. Esto conduce a una
reducción en el costo global del proyecto.

Las métricas del producto se centran en las características del
software y no en cómo fue producido. Un producto no es solo el
software o sistema funcionando sino también los artefactos,
documentos, modelos, módulos o componentes que lo conforman,
por tanto, las métricas del producto deben hacerse sobre la base de
medir cada uno de estos.
Por ejemplo en los artefactos del producto se mide, entre otras
cosas, el tamaño, la calidad (teniendo en cuenta los defectos, la
complejidad, entre otros), la totalidad, rastreabilidad, volatilidad,
esfuerzo.
Aunque las métricas de producto para el software de computadora
son imperfectas, pueden proporcionar una forma sistemática de
valorar la calidad con base en un conjunto de reglas claramente
definidas. También proporcionan comprensión inmediata, en lugar
de hacerlo después de los hechos. Esto permite descubrir y corregir
potenciales problemas antes de que se conviertan en defectos
catastróficos.
Durante las cuatro décadas pasadas, muchos investigadores
intentaron desarrollar una sola métrica que proporcionara una
medida abarcadora de la complejidad del software. Fenton
caracteriza esta investigación como una búsqueda del “imposible
Santo Grial”. Aunque se han propuesto decenas de medidas de
complejidad, cada una toma una visión un poco diferente de lo que
es la complejidad y de qué atributos de un sistema conducen a la
complejidad. Aunque existe la necesidad de medir y de controlar la
complejidad del software, y si bien un solo valor de esta métrica de
calidad es difícil de derivar, es posible desarrollar medidas de
diferentes atributos internos de programa (por ejemplo,
modularidad efectiva, independencia funcional y otros atributos,
entre otros). Estas medidas y las métricas derivadas de ellas pueden
usarse como indicadores independientes de la calidad de los
modelos de requerimientos y de diseño.

El principal objetivo de los ingenieros del software es producir un
sistema, aplicación o producto de alta calidad, para lo cual emplean
métodos y herramientas efectivas dentro del contexto de un
proceso maduro de desarrollo del software y además deben
desarrollar mediciones que den como resultado sistemas de alta
calidad. Para obtener esta evaluación, el ingeniero debe utilizar
medidas técnicas, que evalúan la calidad con objetividad, no con
subjetividad.
En la norma ISO 9126 se proponen un grupo de métricas que
atribuyen a los factores de calidad.
A pesar del avance en el desarrollo de software y las tecnologías,
con el paso de los años los atributos que proporcionan una
indicación de la calidad del software siguen siendo los mismos, en
este sentido en inevitable mencionar el trabajo desarrollado por
McCall y Cavano en cuanto a la definición de factores de calidad,
pues a pesar del tiempo, sus estudios han sido una guía para otros
modelos y normas de calidad. La norma ISO 9126 es un ejemplo de
ello, muchas características y subcaracterísticas definidas en la
misma (Ver Tabla 1) hacen referencia a la operación, transición y
revisión del software y aunque no las dividen en estos tres grupos,
señalan entre otras cosas la necesidad de lograr que el software
opere correctamente y con el grado de exactitud requerido, que los
usuarios sean capaces de entenderlo y usarlo, es decir que sea
amigable con quienes interactúen con él, que sea capaz de
responder correctamente ante fallos o cambios del entorno y que
proporcione una ejecución o desempeño apropiado, teniendo en
cuenta los recursos utilizados.
PROPUESTA DE MÉTRICAS
Las métricas propuestas miden el desarrollo de los proyectos y
ayudan a los líderes y directivos de los mismos en la toma
decisiones y acciones correctivas, así como el mejoramiento
continuo de los procesos, obteniéndose mejores resultados.
Tabla 1. Características de la Norma ISO 9126 y aspectos que atiende cada una
En el área de proceso, la captura de requisitos en una correcta

gestión de requisitos contribuye, en gran medida, al éxito de los
proyectos de software, aportando el entendimiento y la
comprensión de los problemas que se necesitan solucionar y cómo
resolverlos, definiendo con claridad, sin ambigüedades, en forma
consistente y compacta lo que se desea producir.
Las métricas propuestas fueron:
Entendimiento de los requisitos: referida a la capacidad de
entender el significado de los requisitos, o sea que no exista
ambigüedad, que cada requisito tenga una sola interpretación.
Estabilidad de los requisitos: referida a los cambios que sufren los
requisitos a lo largo de todo el ciclo de vida del software incluyendo
la eliminación, inserción y modificación, estos continuos cambios en
la especificación de los requisitos traen consigo un atraso en el
cronograma de trabajo.

La elaboración del plan de proyecto es otra de las áreas en las que
se propusieron métricas. El plan constituye una guía para la
realización y el control del proyecto y sus actividades, en él se
asignan las responsabilidades, recursos y fechas de cumplimiento a
las tareas. El plan incluye estimación de los elementos de trabajo y
tareas, recursos necesarios, negociación de compromisos,
establecimiento de un calendario, e identificación y análisis de los
posibles riesgos que pueda tener el proyecto.
Dentro de la planificación del proyecto se proponen las siguientes
métricas relacionadas con las tareas a cumplir, los plazos destinados
a las mismas, el tiempo, esfuerzo y productividad.
Porcentaje de tareas completadas: con el objetivo de llevar un
registro de las mediciones de las tareas que se desarrollan durante
el proyecto, pues de esta manera pueden realizarse mejores
asignaciones de recursos y tiempo, así como tener una medida del
progreso del trabajo realizado respecto al planificado teniendo en
cuenta el cumplimiento de las tareas.
Porcentaje de error de estimación de Tamaño: teniendo registros
de cuanto puede desviarse el tamaño real del software respecto al
planificado pueden realizarse mejores estimaciones para futuros
trabajos con características similares, de manera que pueda
minimizarse lo más posible el porcentaje de error en la estimación
del tamaño. La estimación del tamaño es un punto de partida para
realizar cálculos y estimaciones de tiempo, costo y esfuerzo.
Porcentaje de error de estimación de Tiempo: de manera análoga
a la métrica anterior también puede analizarse el error de
estimación del tiempo. Estos registros ayudarán a hacer mejores
estimaciones de tiempo para trabajos futuros.

Productividad: con el objetivo de calcular la producción de código
por unidad de tiempo y el esfuerzo necesario para desarrollar un
software. A medida que se avanza en los ciclos de desarrollo del
proyecto, la productividad se incrementa.
Otra de las áreas es la gestión de riesgos, en la que pueden

identificarse tempranamente los posibles riesgos y tomar medidas
correctivas para mitigarlos a tiempo, estos deben tenerse en cuenta
para decidir si se continúa con el proyecto.
Esta es una de las actividades que se inicia en la primera etapa de
un proyecto y se desarrolla a lo largo de todo su ciclo de vida
llegando finalmente hasta la aceptación del producto obtenido.
Medición de la Identificación de los Riesgos: es una medida para
guardar los riesgos más comunes en cada una de las etapas del
desarrollo del software así como las consecuencias que traen
consigo cada uno de ellos (el incremento de los costos, la
cancelación del proyecto, la insatisfacción del cliente, entre otras),
de manera tal que al cabo de cierto tiempo, guardando estos
registros históricos, al comenzar un nuevo proyecto se tengan
identificados los posibles riesgos y prevenirlos, valorando además
su repercusión en cuanto al alcance (cuánto afecta) y la duración
(por cuánto tiempo se manifiesta).
Probabilidad de que ocurran riesgos de un mismo tipo: calculando
la probabilidad de ocurrencia de riesgos de un tipo determinado
(personal, organizativos, de herramientas, de requerimientos, de
estimación, de presupuesto, entre otros), se logrará organizarlos y,
según la prioridad, mitigarlos para contrarrestar los efectos que
puedan ocasionar al sistema.

Efectividad de la mitigación de riesgos: con el objetivo de
determinar la relación existente entre los riesgos mitigados y el
total de riesgos identificados. Guardando estos datos puede
conocerse cuán efectivos han sido los planes de mitigación de
riesgo, o sea ya se tendrá un conocimiento de las soluciones que
fueron efectivas y por lo tanto pueden ser usadas nuevamente para
mitigar riesgos similares a los resueltos.
Finalmente la etapa de prueba que es tan o más importante que

todas las realizadas hasta el momento, en ella se refleja la calidad
con que ha sido llevada a cabo la proyección del sistema. En esta
etapa no se puede asegurar la ausencia de defectos solo puede
demostrarse la existencia de los mismos. En todas las fases del
desarrollo del proyecto hay que probar el software que se va
construyendo y resulta muy importante definir un conjunto de
mediciones para guardar los resultados de las mismas de manera
que aporten información relevante para pruebas sucesivas.
Las métricas utilizadas durante la fase de pruebas, junto con las
técnicas de estimación adecuadas dan soporte para predecir y
controlar los defectos esperados, la duración de las pruebas, los
recursos dedicados, los defectos remanentes, etc.
Rendimiento de la eliminación de defectos: con el objetivo de
conocer la relación entre los defectos eliminados y todos los
existentes en una etapa determinada del proyecto de software. Es
importante que todos los defectos sean encontrados y eliminados
en la etapa que se esté analizando y se reduzcan los defectos
evadidos.
Integridad de la implementación funcional: es una medida de
cuán completa ha sido la implementación según la especificación de
requisitos, se detectan el número de funciones perdidas, aquellas
que fueron descritas en la especificación de requisitos y no fueron
implementadas.

Con esta métrica se evalúa la completitud de la implementación, si
se tienen muchas funcionalidades perdidas, no si se desarrolló una
buena implementación, lo cual implicará la toma de acciones
correctivas para controlar este proceso de manera tal que no se vea
afectada la calidad del producto final.
Cobertura de las pruebas: indica cómo se van cumpliendo los casos
de prueba especificados, por lo tanto mientras mayor sea la
cobertura, mayor número de casos de prueba se estarán
cumpliendo, de esta manera se llevará un control del cumplimiento
de los casos de prueba requeridos para cubrir los requisitos lo que,
por supuesto, da una medida de cuan correctamente se está
desarrollando el proceso de prueba.
La madurez de las pruebas: es un indicador de qué tan bien se esta
desarrollando el proceso de pruebas, no solo se preocupa de la
completitud de los casos de prueba, según los definidos para
cumplir los requisitos, sino que también se interesa por cuales han
obtenido resultados satisfactorios, para ello es necesario llevar un
control de los casos de prueba que arrojaron resultados
satisfactorios y el total de los casos de prueba definidos para el
cumplimiento de los requisitos.
El porcentaje de defectos por tipo: se calcula con el objetivo de
identificar los tipos de defectos más comunes que puedan
presentarse en cualquiera de las etapas del proceso de desarrollo
del software, es aplicable de manera individual para cada
desarrollador o por equipo de trabajo. Este porcentaje sería de los
tipos de defectos que se encontraron tanto en las revisiones, como
luego en las compilaciones y en las pruebas.

Porcentaje del tiempo total dedicado a las pruebas: es una medida
del porcentaje del tiempo dedicado a las pruebas respecto al
tiempo total del proyecto. El tiempo de la prueba será mayor
mientras más defectos se hayan introducido en el software. Este
tiempo dedicado a las pruebas dependerá en gran medida del
tamaño y complejidad del software que se esté desarrollando, los
proyectos similares al analizado tendrán una referencia para
estimar el tiempo que se debe emplear en las pruebas.

El objetivo primario de las revisiones técnicas formales
(inspección) es encontrar errores durante el proceso para
evitar que se conviertan en defectos después de la entrega
del software. El beneficio obvio de estas inspecciones es el
descubrimiento de errores al principio para que no se propaguen
al paso siguiente del proceso de desarrollo del software
(catarata de errores de Mizuno).
Una serie de estudios (TRW, Nippon Electric y Mitre
Corp., entre otros) indican que las actividades del diseño
introducen entre el 50% y 65% de todos los errores (y en
último lugar, todos los defectos) durante el proceso de
software. Si embargo se ha demostrado que las inspecciones de
software son efectivas en un 75% a la hora de detectar errores.
Los beneficios de aplicar Inspecciones son:
• Reducción de los defectos en el uso del software.
• Reducción de los recursos de desarrollo, sobre todo en las etapas
de codificación y prueba.
• Reducción en los costos de mantenimiento correctivo.
El proceso de inspección
Se puede ver a las inspecciones de software como un
repaso detallado y formal del trabajo en proceso. Pequeños
grupos de trabajadores (4 o 5) estudian el "producto de trabajo”
independientemente y luego se reúnen para examinar el trabajo en
detalle. El “producto de trabajo” representa 200 a 250 líneas de
código; requerimientos, diseño y otros productos de
trabajo son inspeccionados en un tamaño similar. Los productos de
trabajo son considerados en progreso hasta que la inspección y las
correcciones necesarias estén completas.
El tiempo de la inspección varía según cuan familiarizado
esté el inspector con el material.

MANTENIMIENTO
DEL SOFTWARE
TEMA: Mantenimiento,
Reingeniería y Mantenibilidad

El estándar IEEE 1219 define el mantenimiento del software como
"la modificación de un producto de software después de su entrega
para corregir las fallas, mejorar el rendimiento u otros atributos o
para adaptarlo a un cambio en el entorno“.
A su vez, el estándar ISO/IEC 12207 determina el mantenimiento

como "uno de los procesos principales en el ciclo de vida del
software“. Este proceso se activa cuando el producto software sufre
modificaciones en el código y la documentación asociada debido a
un problema o a la necesidad de mejora o adaptación. El objetivo
es modificar el software existente preservando su integridad. Este
proceso incluye la migración y retirada del producto software. El
proceso termina con la retirada del producto software.
Analizando las definiciones, podemos concluir que el

mantenimiento del software es la modificación de un sistema
después de su liberación, para: corregir errores, mejorar el
desempeño y otras propiedades, prevenir futuras fallas o adaptar el
producto a un nuevo ambiente.
En anteriores definiciones de mantenimiento aparecen indicados,

directa o indirectamente, cuatro tipos de mantenimiento:
correctivo, adaptativo, perfectivo o preventivo.

Mantenimiento Correctivo
A pesar de las pruebas y verificaciones que aparecen en etapas
anteriores del ciclo de vida del software, los programas pueden
tener defectos. El mantenimiento correctivo tiene por objetivo
localizar y eliminar los posibles defectos de los programas. Un
defecto en un sistema es una característica del sistema con el
potencial de causar un fallo. Un fallo ocurre cuando el
comportamiento de un sistema es diferente del establecido en la
especificación.
Entre otros, los fallos en el software pueden ser de:
• Procesamiento, por ejemplo, salidas incorrectas de un programa.
• Rendimiento, por ejemplo, tiempo de respuesta demasiado alto
en una búsqueda de información.
• Programación, por ejemplo, inconsistencias en el diseño de un
programa.
• Documentación, por ejemplo, inconsistencias entre la
funcionalidad de un programa y el manual del usuario.
De acuerdo a un estudio estadístico realizado por Grady, en 1994, la

distribución de las causas de los defectos arrojan que el 37,4% de
los defectos se originan en la fase de especificación de requisitos, el
25,5% en la fase de diseño y el 36,3% en la fase de codificación.
Mantenimiento Adaptativo
Este tipo de mantenimiento consiste en la modificación de un
programa debido a cambios en el entorno (hardware o software) en
el cual se ejecuta. Estos cambios pueden afectar al sistema
operativo (cambio a uno más moderno), a la arquitectura física del
sistema informático (paso de una arquitectura de red de área local
a Internet/Intranet) o al entorno de desarrollo del software
(incorporación de nuevos elementos o herramientas).

La envergadura del cambio necesario puede ser muy diferente:
desde un pequeño retoque en la estructura de un módulo hasta
tener que reescribir prácticamente todo el programa para su
ejecución en un ambiente distribuido, en una red.
Los cambios en el entorno software pueden ser de dos clases:

En el entorno de datos, por ejemplo, al dejar de trabajar con un
sistema de archivos clásicos y sustituirlo por un sistema de gestión
de bases de datos relacionales.
En el entorno de los procesos, por ejemplo, migrando a una nueva
plataforma de desarrollo con componentes distribuidos, Java,
ActiveX, etc.
El mantenimiento adaptativo es cada vez más usual debido
principalmente al cambio, cada vez más rápido, de los diversos
aspectos de la informática: nuevas generaciones de hardware cada
dos años, nuevos sistemas operativos que se anuncian
regularmente y mejoras en los periféricos o en otros elementos del
sistema. Frente a esto, la vida útil de un sistema software puede
superar fácilmente los diez años.
Mantenimiento Perfectivo
Cambio en la especificación, normalmente debido a cambios en los
requisitos de un producto software, implican un nuevo tipo de
mantenimiento llamado perfectivo. La casuística es muy variada.
Desde algo tan simple como cambiar el formato de impresión de un
informe, hasta la incorporación de un nuevo módulo aplicativo.
Podemos definir el mantenimiento perfectivo como el conjunto de
actividades para mejorar o añadir nuevas funcionalidades
requeridas por el usuario.
Algunos autores dividen este tipo de mantenimiento en dos:

• Mantenimiento de Ampliación: orientado a la incorporación de
nuevas funcionalidades.
• Mantenimiento de Eficiencia: que busca la mejora de la eficiencia
de ejecución.
Este tipo de mantenimiento aumenta cuando un producto software

tiene éxito comercial y es utilizado por muchos usuarios, ya que
cuanto más se utiliza un software, más peticiones de los usuarios se
reciben demandando nuevas funcionalidades o mejoras en las
existentes.
Mantenimiento Preventivo
Este último tipo de mantenimiento consiste en la modificación del
software para mejorar sus propiedades (por ejemplo, aumentando
su calidad y/o su mantenibilidad) sin alterar sus especificaciones
funcionales. Por ejemplo, se pueden incluir sentencias que
comprueben la validez de los datos de entrada, reestructurar los
programas para mejorar su legibilidad, o bien incluir nuevos
comentarios que faciliten la posterior compresión del programa.
Este tipo de mantenimiento es el que más partido saca de las
técnicas de ingeniería inversa y reingeniería.
En algunos casos se ha planteado el Mantenimiento para la
Reutilización, consistente en modificar el software (buscando y
modificando componentes para incluirlos en bibliotecas) para que
sea más fácilmente reutilizable. En realidad este tipo de
mantenimiento es preventivo, especializado en mejorar la
propiedad de reusabilidad del software.

El desconocimiento de las actividades que implica el
mantenimiento del software puede inducir a minusvalorar su
importancia, y se tiende a asociar el mantenimiento del software
con la corrección de errores en los programas. Por esta causa la
impresión más generalizada entre los gestores, usuarios, e incluso
entre los propios informáticos, es que la mayor parte del
mantenimiento que se realiza en el mundo es de tipo correctivo. Sin
embargo varios autores sostienen que esta impresión es
equivocada, indicando que el mayor porcentaje de esfuerzo se
aplica al mantenimiento perfectivo, con un 60%. Para el
mantenimiento correctivo, el esfuerzo se ubica con el 17%; el
preventivo con el 5% y, finalmente, el mantenimiento adaptativo
con el 18%.
Se han identificado diferentes tipos de actividades que se realizan
en cada modificación del software, a saber:
• Análisis de impacto y de costos/beneficios: esta actividad se
dedica a analizar diferentes alternativas de implementación y/o a
comprobar su impacto en la planificación, costo y facilidad de
operación.
• Comprensión del cambio: puede consistir en localizar el error y
determinar su causa, o bien en comprender los requisitos de una
mejora solicitada.
• Diseño del cambio: se refiere al diseño propuesto para el cambio
pudiéndose incluir un rediseño del sistema.
• Codificación y pruebas unitarias: se codifica y prueba el
funcionamiento de cada componente modificado.
• Inspección, certificación y consultoría: esta actividad se dedica a
inspeccionar el cambio, comprobar otros diseños, reuniones de
inspección, etc.
• Pruebas de integración: se refiere a comprobar la integración de
los componentes modificados con el resto del sistema.

• Pruebas de aceptación: en esta actividad, el usuario comprueba,
junto al personal encargado del mantenimiento, la adecuación del
cambio a sus necesidades.
• Pruebas de regresión: en esta actividad se somete el software
modificado a casos de pruebas previamente almacenados y por los
que ya pasó.
• Documentación del sistema: se revisa y reescribe, en caso
necesario, la documentación del sistema para que se ajuste al
producto software ya modificado.
• Otra documentación (del usuario, por ejemplo): se revisan y
reescriben, en caso necesario, los diferentes manuales de usuario y
otra documentación, excepto la documentación del sistema.
• Otras actividades, como las dedicadas a la gestión del proyecto
de mantenimiento.
La distribución del esfuerzo en cada grupo de actividades, según se

trate de mantenimiento correctivo o perfectivo, es la siguiente:
• La proporción de esfuerzo dedicado a comprensión es mucho
mayor en el caso de mantenimiento correctivo que en el perfectivo.
• La proporción de esfuerzo empleado en inspección, certificación
y consultoría es mucho mayor en el caso de mantenimiento
perfectivo que en el correctivo.
• La proporción de esfuerzo dedicado a diseño, codificación y
pruebas es muy similar en ambos tipos de mantenimiento.

Múltiples estudios señalan que el mantenimiento es la parte más
costosa del ciclo de vida del software. Está comprobado que el
costo de mantenimiento de un producto software, a lo largo de
toda su vida útil, supone más del doble que los costos de su
desarrollo. La tendencia es creciente con el paso del tiempo, en
porcentaje, que demuestra lo que el mantenimiento representa
respecto del costo total.
De acuerdo a eso, la evolución del costo de mantenimiento es:
• En los años 70: 35% - 40%.
• En 1976: 60%.
• En los años 1980 – 1984: 55%.
• En los años 80: 60%.
• En 1987: 67%.
• En 1987: 67%.
• En los años 1985 – 1989: 75%.
• En 1990: 80%.
• Años 1990: 90%.
Los programadores pasan el 61% de su vida profesional realizando
trabajos de mantenimiento, y sólo un 39% nuevos desarrollos.
Algunos autores estiman que la situación puede llegar a ser casi
insostenible, ya que existen empresas que se acercan al 95% de los
recursos dedicados al mantenimiento con lo cual se hace imposible
el desarrollo de nuevos productos software. Esta situación se
conoce como Barrera de Mantenimiento. En general, el porcentaje
de recursos necesarios para mantenimiento se incrementa a
medida que se produce más software y la producción de éste ha
tenido, desde sus inicios, una tendencia siempre creciente.
Sin embargo, los estudios sobre la situación del mercado comercial
del mantenimiento del software son relativamente escasos, pero se
puede mencionar que, en Francia, se han señalado unos gastos en
software de 48 miles de millones de francos en 1991, de los cuales
el mantenimiento supuso 34 miles de millones, es decir, más del
70%.
También es preciso señalar que algunos hechos trascendentales han
confirmado la importancia económica y social del mantenimiento
del software, tales como el denominado “Efecto 2000” a escala
mundial y particularmente, en el ámbito de la Unión Europea, la
adaptación a la implantación de la nueva moneda , el Euro. Ambos
casos son situaciones caracterizadas porque debe realizarse el
mantenimiento de miles de aplicaciones software, con decenas de
millones de líneas de código.
Son varias las causas de que en la mayoría de las organizaciones
actuales se requiera mucho trabajo de mantenimiento. En primer
lugar, una gran cantidad de software que existe actualmente ha sido
desarrollado hace más de 10 o 20 años. Aunque estos programas
fuesen creados utilizando las mejores técnicas de diseño y
codificación existentes en su momento se construyeron con
restricciones de tamaño y espacio de almacenamiento y se
desarrollaron con herramientas tecnológicamente limitadas. En
segundo lugar, estos programas han sufrido una o varias
migraciones a nuevas plataformas o sistemas operativos. Y, por
último, han experimentado múltiples modificaciones para
mejorarlos y adaptarlos a las nuevas necesidades de los usuarios.
Todos estos cambios se realizaron sin tener en cuenta la
arquitectura general del sistema. El resultado de todo ello es la
existencia de sistemas software que tienen que seguir funcionando
en la actualidad con una baja calidad (diseño pobre de las
estructuras de datos, mala codificación, lógica defectuosa y
documentación escasa).
Cuando se planifican los costos de mantenimiento, los analistas
programadores experimentados tienen la impresión de que el
mantenimiento es algo descontrolado y que nunca se sabe qué va a
pasar. Parece como si el mantenimiento del software fuese un
iceberg del cual sólo se percibe una pequeña parte, pero bajo cuya
superficie se esconde una gran cantidad de problemas potenciales y
de costos encubiertos.
En la parte sumergida de este iceberg se ocultan otros costos,
menos tangibles que los monetarios, pero que pueden ser la causa
de muchas preocupaciones. Un costo intangible del mantenimiento
del software se encuentra en las oportunidades de desarrollo que
se han de posponer o que se pierden, debido a que los recursos
disponibles están dedicados a las tareas de mantenimiento.
Otros costos intangibles son:
• Insatisfacción del cliente cuando no se puede atender, en un
tiempo aceptable, una petición de reparación o modificación que
parezca razonable.
• Los errores ocultos introducidos al cambiar el software durante el
mantenimiento reducen la calidad global del producto.
• Perjuicio en otros trabajos de desarrollo cuando la plantilla tiene
que dejarlos, total o parcialmente, para atender peticiones de
mantenimiento.
En suma, un costo final de mantenimiento del software es la

reducción que se produce en la productividad de los informáticos al
iniciar el mantenimiento de aplicaciones antiguas. Algunos autores
han calculado reducciones de la productividad de 40 a 1, es decir, el
costo de mantener una línea de código puede llegar a ser 40 veces
más alto que el proceso de desarrollo.

La problemática del mantenimiento se resume en realizar el
mantenimiento del software de forma tan rigurosa que la calidad
no se deteriore como resultado de este proceso. La pregunta a
formular es la siguiente: ¿cómo debe mantenerse el software para
preservar su fiabilidad? La respuesta no es fácil y está muy
condicionada.
Durante los pasados 30 años, Manny Lehman y sus colaboradores
realizaron análisis detallados de software de grado industrial y de
sistemas con la intención de desarrollar una teoría unificada para
evolución del software.
Lo más destacado de este análisis es:
• Ley de cambio continuo (1974): El software que se implementó
en un contexto de cómputo del mundo real y que, por tanto,
evolucionará con el tiempo (llamados sistemas tipo E) debe
adaptarse continuamente o de otro modo se volverá
progresivamente menos satisfactorio.
• Ley de complejidad creciente (1974): Conforme un sistema tipo E
evoluciona, su complejidad aumenta, a menos que se haga trabajo
para mantenerlo o reducirlo.
• Ley de autorregulación (1974): El proceso de evolución del
sistema tipo E es autorregulable con medidas de distribución de
producto y de proceso cercanas a lo normal.
• Ley de conservación de estabilidad organizativa (1980): La tasa de
actividad global efectiva promedio en un sistema tipo E en
evolución no varía durante el tiempo de vida del producto.
• Ley de conservación de familiaridad (1980): Conforme un sistema
tipo E evoluciona, todo lo asociado con él: desarrolladores,
personal de ventas, usuarios, etc., deben mantener el dominio de
su contenido y comportamiento para lograr evolución satisfactoria.
El crecimiento excesivo disminuye dicho dominio. Por tanto, el
crecimiento incremental promedio permanece sin variación
conforme el sistema evoluciona.

• Ley de crecimiento continuo (1980): El contenido funcional de los
sistemas tipo E debe aumentar continuamente para mantener la
satisfacción del usuario durante su tiempo de vida.
• Ley de declive de la calidad (1996): La calidad de los sistemas tipo
E declinará, a menos que se mantengan y adapten rigurosamente a
los cambios del entorno operativo.
• Ley de realimentación del sistema (1996): Los procesos evolutivos
tipo E constituyen sistemas de realimentación multinivel,
multibucle y multiagente, y deben tratarse como tales para lograr
mejora significativa sobre cualquier base razonable.
Las leyes que definieron Lehman y sus colegas son parte inherente
de una realidad de la ingeniería de software.
Problemas del mantenimiento

A menudo el mantenimiento es realizado de manera ad hoc en un
estado libre establecido por el propio programador. Esto es debido
a que prácticamente todas las metodologías se han centrado en el
desarrollo de nuevos sistemas y no han tenido en cuenta la
importancia del mantenimiento. Cambio tras cambio, los programas
tienden a ser menos estructurados, lo que se manifiesta en una
documentación desfasada, lo cual contribuye a costos de
mantenimiento del software muy altos.
Es muy habitual que los sistemas que están siendo sometidos a
mantenimiento sean cada vez más difíciles de cambiar, lo cual
implica que los cambios en un programa por actividades de
mantenimiento dificultan la posterior comprensión de la
funcionalidad del programa. La falta de una metodología adecuada
suele conducir a que los usuarios participen poco durante el
desarrollo del sistema software. Y finalmente, sumado a los
problemas técnicos anteriores, también pueden haber problemas
de gestión.

Las soluciones al problema del mantenimiento pueden dividirse en
dos categorías: las que proponen soluciones de gestión
(organizativas) y las que proponen soluciones técnicas
(metodologías y herramientas).
Soluciones de gestión
En términos financieros, el mantenimiento del software puede ser
visto como un continuo consumidor de recursos, mientras que los
beneficios no están claros ni cuantificados. Para ayudar a evitar esta
situación se necesita un mayor apoyo por parte de la dirección de
las organizaciones para las actividades de mantenimiento del
software. Para ello es necesario que los seniors de las
organizaciones sean conscientes de:
• La importancia de las tecnologías de la información para la
organización.
• Que el software es un activo corporativo que puede suponer una
ventaja competitiva.
Recursos dedicados al mantenimiento

El recurso fundamental y clave es el humano. Por tanto, una
manera de mejorar el mantenimiento del software podría ser
constituir un grupo separado de programadores dedicado a
mantener código antiguo.
Gestión de la calidad
El aumento de los recursos humanos y económicos dedicados al
mantenimiento del software puede suponer una solución a corto
plazo, pero para resolver el problema a largo plazo se hace
necesario adoptar una aproximación que permita mejorar la calidad
del proceso en su conjunto. Lo cual implicaría técnicas estándares
para la descomposición del software en entidades funcionales,
estándares de documentación, diseño paso a paso en cada nivel de
descomposición del software, uso de código estructurado, etc.
Soluciones técnicas
Éstas son de dos clases: herramientas y métodos. Las primeras
sirven para soportar de forma más efectiva y cómoda los segundos.
Estas herramientas han sido diseñadas para ayudar al personal de
mantenimiento a comprender el programa y a probar sus
modificaciones para asegurar que no han sido introducidos errores.
Los principales métodos empleados en el mantenimiento del

software son:
• Reingeniería: consiste en el examen y modificación de un sistema
para reconstruirlo en una nueva forma.
• Ingeniería Inversa: es el proceso de analizar un sistema para
identificar sus componentes y las interrelaciones que existen entre
ellos, así como para crear representaciones del sistema en otra
forma o en un nivel de abstracción más elevado.
• Reestructuración del software: consiste en la modificación del
software para hacerlo más fácil de entender y cambiar o menos
susceptible de incluir errores en cambios posteriores. Se diferencia
de la ingeniería inversa en que el software reestructurado tiene el
mismo nivel de abstracción que el original.
También se puede mencionar la Transformación de Programas, este

método parte de una especificación o programa ya existente para
obtener otro programa equivalente por medio de una serie de
transformaciones sucesivas. Estas transformaciones consisten en un
cambio realizado en el código fuente del programa de forma que la
semántica del programa no cambia.

La mantenibilidad o facilidad de mantenimiento del software se
puede definir como la medida cualitativa de la facilidad de
comprender, corregir, adaptar y/o mejorar el software.
Los factores que influyen en la mantenibilidad son los siguientes:
• Falta de cuidado en las fases de diseño, codificación o prueba.
• Pobre configuración del producto software.
• Adecuada cualificación del equipo de desarrolladores de
software.
• Estructura del software fácil de comprender.
• Facilidad de uso del sistema.
• Empleo de lenguajes de programación y sistemas operativos
estandarizados.
• Estructura estandarizada de la documentación.
• Documentación disponible de los casos de prueba.
• Incorporación en el sistema de facilidades de depuración.
• Disponibilidad del equipo (computadora y periféricos) adecuados
para realizar el mantenimiento.
• Disponibilidad de la persona o grupo que desarrolló
originalmente el software.
• Planificación del mantenimiento.
El último factor señalado es, seguramente, el que más influye

positivamente en la mantenibilidad del software. Si se ve al
software como un producto que estará sujeto a cambios casi con
total seguridad, las etapas previas del ciclo de vida se podrán
realizar de forma que aumenten las posibilidades de producir
software más fácilmente mantenible.

En los últimos años se ha realizado un considerable esfuerzo en la
comunidad internacional para elaborar estándares, tanto para el
ciclo de vida completo del software como para la fase de
mantenimiento.
Diversos organismos e instituciones han elaborado propuestas para
contemplar el objetivo de la mantenibilidad en el proceso de
desarrollo de software.
Algunas de las propuestas formuladas son las siguientes:
• U.S. Gobierno Federal.
• U.S. Air Force.
• National Institute of Science and Technology.
• IEEE Computer Society.
• ISO/IEC.
• Agencia Espacial Europea.
Fruto de estos trabajos han sido publicados diversos estándares por

parte de IEEE y de ISO que tienen relación directa o indirecta con el
problema del mantenimiento del software:
• Para los procesos del ciclo de vida del software: ISO 12207, IEEE
1074.
• Para la calidad del software y sus métricas: ISO 9126, IEEE 1061.
• Para el mantenimiento del software: IEEE 1219 y el nuevo
estándar ISO 14764.
Los estándares para los procesos del ciclo de vida del software
permiten integrar y asociar el proceso de mantenimiento con los
demás procesos existentes para el software. Los estándares de
calidad del software interesan en mantenimiento del software
porque los factores de calidad del software (especialmente la
complejidad y la mantenibilidad) inciden directamente sobre el
esfuerzo de mantenimiento necesario.

El término ingeniería inversa tiene su origen en el mundo del
hardware. Una compañía desensambla un producto de hardware
de otra empresa con la intención de entender los “secretos” de
diseño y fabricación de su competidor. Dichos secretos podrían
entenderse fácilmente si se obtuvieran las especificaciones de
diseño y fabricación. Pero esos documentos son propiedad de la
empresa competidora y no están disponibles para la compañía que
hace la ingeniería inversa. En esencia, la ingeniería inversa exitosa
deriva en una o más especificaciones de diseño y fabricación para
un producto al examinar especímenes reales del mismo.
La ingeniería inversa para el software es muy similar. No obstante,
en la mayoría de los casos, el programa que se va a someter a
ingeniería inversa no es de un competidor: es el propio trabajo de la
compañía (con frecuencia, elaborado muchos años atrás). Los
“secretos” por entender son oscuros porque jamás se desarrollaron
especificaciones. Por tanto, la ingeniería inversa para software es el
proceso de analizar un programa con la intención de crear una
representación del mismo en un nivel superior de abstracción que
el código fuente. La ingeniería inversa es un proceso de
recuperación de diseño. Las herramientas de ingeniería inversa
extraen información de diseño de datos, arquitectónico y
procedimental de un programa existente.

Reestructuración de código. El tipo más común de reingeniería (en
realidad, en este caso es cuestionable el uso del término
reingeniería) es la reestructuración de código. Algunos sistemas
heredados tienen una arquitectura de programa relativamente
sólida, pero los módulos individuales fueron codificados en una
forma que los hace difíciles de entender, poner a prueba y
mantener. En tales casos, el código dentro de los módulos
sospechosos puede reestructurarse.
Para realizar esta actividad se analiza el código fuente con una
herramienta de reestructuración.
Las violaciones a los constructos de programación estructurada se
anotan y luego el código se reestructura (esto puede hacerse
automáticamente) o incluso se reescribe en un lenguaje de
programación más moderno. El código reestructurado resultante se
revisa y pone a prueba para garantizar que no se introdujeron
anomalías. La documentación de código interna se actualiza.

Aunque la mantenibilidad del software es una propiedad difícil de
cuantificar puede medirse indirectamente realizando una
evaluación cuantitativa de los atributos que la caracterizan. Para
ello, algunos autores han propuesto diversas clases de métricas de
mantenibilidad:
• De esfuerzo: se propone evaluar el esfuerzo requerido durante la
fase de mantenimiento mediante métricas que indican el tiempo
dedicado a las diversas tareas realizadas.
• De complejidad: se sugiere utilizar métricas de complejidad para
evaluar la mantenibilidad.
• De estructura: se analiza la correlación entre la estructura de un
programa y su facilidad de mantenimiento.

Teoria Testing

Cargado por

Copyright:

Formatos disponibles

Teoria Testing

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Teoria Testing

Cargado por

Copyright:

Formatos disponibles

INGENIERÍA INFORMÁTICA

Ing. David Sánchez Rivero

Figura 1. Ciclo de vida del software

El concepto de calidad de software, según R. Pressman se asocia a

Calidad del Software & Testing 3

Calidad del Software & Testing 4

Conceptos relacionados con la gestión de la calidad

Calidad del Software & Testing 5

Calidad del Software & Testing 7

Calidad del Software & Testing 8

Calidad del Software & Testing 9

Calidad a nivel de producto

Calidad a nivel de proceso

Calidad del Software & Testing 10

Modelos a nivel de producto

Boehm: Es un modelo incremental, dividido en regiones de tareas y

WebQEM: es una metodología de evaluación de calidad de sitios

ISO 25000: También llamadas como SQuaRE, cuyo propósito es

Calidad del Software & Testing 12

Calidad del Software & Testing 13

Calidad del Software & Testing 14

Calidad del Software & Testing 15

Ing. David Sánchez Rivero

Calidad del Software & Testing 2

Calidad del Software & Testing 3

Calidad del Software & Testing 4

Calidad del Software & Testing 5

Calidad del Software & Testing 6

Calidad del Software & Testing 7

Calidad del Software & Testing 8

Calidad del Software & Testing 9

Calidad del Software & Testing 10

Calidad del Software & Testing 11

Calidad del Software & Testing 12

Ing. David Sánchez Rivero

Calidad del Software & Testing 2

Modelos de calidad a nivel de producto

Modelos de calidad a nivel de proceso

Calidad del Software & Testing 3

GQM o Goal Question Metric: Se enfoca a proporcionar una forma

Boehm: Es un modelo incremental, dividido en regiones de tareas y

FURPS: Modelo desarrollado por Hewlett-Packard, cuyo nombre

GILB: Modelo de calidad que orienta la evaluación de software a

Calidad del Software & Testing 4

SQAE o Software Quality Assessment Exercise: Este modelo,

WebQEM: es una metodología de evaluación de calidad de sitios

ISO 25000: También llamadas como SQuaRE, cuyo propósito es

Calidad del Software & Testing 5

ISO/IEC 15504: Permite adaptar la evaluación para procesos en

Bootstrap: Metodología de evaluación que permite la mejora de

Calidad del Software & Testing 6

Personal Software Process (PSP): Este modelo está enfocado al

Team Software Process (TSP): TSP es la fase posterior de PSP, está

IEEE/EIA 12207: Este estándar establece un marco de trabajo

Calidad del Software & Testing 7

ISO 90003: Conjunto de estándares utilizados para el desarrollo,

CMMI (Capability Maturity Model Integration): Es de los modelos

ISO/IEC 20000: El objetivo principal de esta norma es el de avalar

Calidad del Software & Testing 8

Normas ISO 9000