Calidad de Software

CALIDAD DE SOFTWARE
MATERIAL DE ESTUDIO
ING. FELIPE ALIAGA CAVERO
2010-II
CALIDAD DE SOFTWARE
CONTENIDO
UNIDAD DIDÁCTICA N° 01:
FUNDAMENTOS DE LA CALIDAD DEL SOFTWARE
MODELOS Y ESTÁNDARES DE CALIDAD DE SOFTWARE
MÉTRICAS DE CALIDAD DEL SOFTWARE
EJECUCIÓN DEL CONTROL DE CALIDAD DE SOFTWARE
ING. FELIPE OMAR ALIAGA CAVERO 2

CALIDAD DE SOFTWARE
UNIDAD DIDÁCTICA N° 01
FUNDAMENTOS DE LA CALIDAD DE SOFTWARE
FUNDAMENTOS DE CALIDAD
Introducción
La calidad es el factor básico de decisión del cliente para un número de productos y servicios
que hoy crece en forma explosiva. La calidad ha llegado a ser la fuerza más importante y
única que lleva al éxito organizacional y al crecimiento de la compañía en mercados
nacionales e internacionales. Los rendimientos de programas de calidad fuerte y eficiente
están generando excelentes resultados de utilidades en empresas con estrategias de calidad
eficientes.
ficientes. Esto está demostrado por los importantes aumentos en la penetración del
mercado, por mejoras importantes en la productividad total, por los costos muchos menores
de calidad y por un liderazgo competitivo más fuerte. Cuando se menciona el término
"calidad", por lo general lo asociamos con productos o servicios excelentes, que satisfacen
nuestras expectativas y, más aún, las rebasan. Tales expectativas se definen en función del
uso que se le dará al producto o servicio en cuestión y de su respectivo
respectiv precio de venta.
Cuando un producto mejora nuestras expectativas estamos hablando de calidad. Es decir, se
trata de una cualidad cuya valoración dependerá de lo que se perciba.
De acuerdo a la norma A3 – 1987 ANSI / ASQC, Calidad es la totalidad de aspectos

aspe y
características de un producto o servicio que permiten satisfacer necesidades implícita o
explícitamente formuladas. Estas últimas se definen mediante un contrato, en tanto que las
primeras se definen según las condiciones que imperen en el mercado, aunque es necesario
también determinarlas y definirlas.
Debido a la gran variación de resultados de calidad, la búsqueda genuina del éxito en la

calidad se ha convertido en un asunto de gran interés en la administración de las compañías
de todo el mundo.. Y la experiencia está abriendo una base fundamental para lograr ese éxito.
La calidad es en esencia una forma de administrar a la organización. Como finanzas y
mercadotecnia, la calidad ha llegado a ser ahora un elemento esencial de la administración
moderna.
erna. Y la eficiencia en la administración de la calidad se ha convertido en una condición
necesaria para la eficiencia de la administración industrial en sí.
Origen de la Calidad
Como nos tienen acostumbrados, los japoneses fueron los pioneros. La II Guerra
Gu Mundial dejó
la economía nipona en una situación catastrófica, con unos productos poco competitivos que
no tenían cabida en los mercados internacionales. Los japoneses no tardaron en reaccionar:
se lanzaron al mercado gracias a la adopción de los sistemas
sistemas de calidad. Los resultados fueron
que Japón registró un espectacular crecimiento. La iniciativa nipona pronto se transmitió a
otras zonas del planeta. Europa tardó algo más, pero también fueron los años 80 los del
impulso definitivo. En 1988 nace la European
European Foundation for Quality Managment (EFQM),
organización que apuesta por los modelos de gestión de calidad total (GTC o TQM),
estrategias encaminadas a optimizar los recursos, reducir costes y mejorar los resultados, con
el objetivo de perfeccionar constantemente
co el proceso productivo. La implantación de la
calidad total es un proceso largo y complicado, supone cambiar la filosofía de la empresa y los
modos de gestión de sus responsables; se debe elegir un problema concreto, y analizar el
punto en donde e esté fallando la empresa.

CALIDAD DE SOFTWARE
Los principios de gestión de la calidad total son sencillos de entender, pero

complicados de asimilar:
• El sistema parte de la búsqueda de la satisfacción del cliente, en todos sus aspectos.
• Un primer paso es la búsqueda de la calidad
calidad de los productos/servicios.
• Pero habrá que tener en claro que el producto/servicio ya no será el punto principal
de calidad.
Los principios elementales son los siguientes:

• De poco sirve imponer de forma autoritaria la mejora en cada puesto de trabajo.
tra
• La calidad la produce el último eslabón que termina el producto ó que está en
contacto con el cliente pero nunca el director general.
• El directivo tiene que estar convencido de la necesidad de la calidad.
Concepto de Calidad
Es cuando en una organización se determinan las actividades y los integrantes de la misma se

encuentran haciendo lo que tienen que hacer, lo están haciendo bien, para brindarle una
satisfacción total al cliente.
Análisis del concepto

“haciendo lo que tienen que hacer”, se refiere a:
• Determinación de las actividades
• Conocimiento de los requisitos a cumplir
• Adiestramiento sobre esos requisitos (capacitación)
• Cumplimiento estricto de esos requisitos
Si se conocen los requisitos no se necesita supervisión, ya que se sabe qué hacer.
“lo están haciendo bien”

Implica la predisposición o la integración de la organización (el compromiso). Es la diferencia
entre tener y querer ir a trabajar, creando un mejor ambiente de trabajo.
“brindar satisfacción total al cliente”

Calidad Total es cuando en la organización, los integrantes se encuentran cumpliendo
exactamente con todos los requisitos establecidos y normalizados hacia la del la búsqueda del
Cero Defecto, para brindarle satisfacción total al cliente.
Cliente es todo aquel que se ve afectado por lo que haga o deje de hacer. Es aquel que
depende de mí, es decir, tiene una dependencia directa; aquel que me sigue en la línea
(cliente interno) y todos aquellos que me dependen (razón trascendental). Calidad Total no se
limita a unana técnica administrativa o de gestión, sino que su concepción es mucho más
profunda, ya que empieza y termina con las personas, es decir que es una filosofía que se
demuestra en el ser, pensar y actuar de las personas de Calidad. Personas de Calidad
obtienen
nen productos de calidad y brindan servicios de calidad.
Se ha definido al Mejoramiento del personal como una forma de lograr la calidad total, y como
una conversión en el mecanismo viable y accesible al que las empresas de los países en vías
de desarrollo
o cierren la brecha tecnológica que mantienen con respecto al mundo competitivo
y desarrollado. Para mejorar un proceso y llegar a la calidad total, y ser en consecuencia más
competitivos, es necesario cambiar dicho proceso, para hacerlo más efectivo, eficiente
efic y
adaptable. Qué cambiar y cómo cambiar depende del enfoque específico del empresario y del
proceso.
LA CLAVE DEL ÉXITO ES LA CALIDAD TOTAL DE MANTENER SISTEMÁTICAMENTE

VENTAJAS QUE LE PERMITAN ALCANZAR DETERMINADA POSICIÓN EN EL
ENTORNO SOCIOECONÓMICO.
SOCIOECONÓM

CALIDAD DE SOFTWARE
El término calidad total es muy utilizado en los medios empresariales, políticos y

socioeconómicos en general. A ello se debe la ampliación del marco de referencia de nuestros
agentes económicos que han pasado de una actitud auto protectora a un planteamiento
plant más
abierto, expansivo y proactivo.
La ventaja comparativa de una empresa estaría en su habilidad, recursos, conocimientos y

atributos, etc., de los que dispone dicha empresa, los mismos de los que carecen sus
competidores o que estos tienen en menormenor medida, que hace posible la obtención de unos
rendimientos superiores a los de aquellos. El uso de estos conceptos supone una continua
orientación hacia el entorno y una actitud estratégica por parte de las empresas grandes
como en las pequeñas, en las de reciente creación o en las maduras y en general en cualquier
clase de organización. Por otra parte, el concepto de éxito nos hace pensar en la idea
"excelencia", o sea, con características de eficiencia y eficacia de la organización.
El Concepto de Calidad Total tiene Cuatro Etapas:
1) Hacer
acer de la calidad un socio pleno e igual de la innovación, desde el comienzo del
desarrollo del producto.
2) Poner énfasis en que el diseño de un producto de alta calidad y el proceso coincidan
en forma ascendente,
ascendente no después spués que la planeación de la manufactura haya
congelado ya las alternativas.
3) Hacer
acer de todos los servicios de los proveedores un socio de calidad al comenzar el
diseño; en lugar de un problema de vigilancia de la calidad, más adelante.
4) Hacer
acer de la aceleración
aceleración de la introducción de un nuevo producto – no su retardo –
una medida primaria de la eficacia del programa de calidad de una compañía. El
cuarto punto fundamental es que la calidad y el costo son complementarios y no
objetivos conflictos del negocio.
Estos
stos fundamentos aclaran que el liderazgo de la calidad es hoy en día la clave del éxito del
negocio de las compañías y que ello se suma a las economías nacionales. En correspondencia,
las iniciativas nacionales y regionales están resultando de importancia creciente en el fomento
del liderazgo de la calidad.
¿Qué es Calidad Total?
La calidad total es un concepto, una filosofía, una estrategia, un modelo de hacer negocios y
está localizado hacia el cliente. La calidad total no solo se refiere al producto o servicio en sí,
sino que es la mejoría permanente del aspecto organizacional, gerencial; tomando una
empresa como una máquina gigantesca, donde cada trabajador, desde el gerente, hasta el
funcionario del más bajo nivel jerárquico está comprometido con los objetivos empresariales.
Para que la calidad total se logre a plenitud, es necesario que se rescaten los valores morales
básicos de la sociedad y es aquí, donde el empresario juega un papel fundamental,
empezando por la educación previa de sus trabajadores
trabajadores para conseguir una población laboral
más predispuesta, con mejor capacidad de asimilar los problemas de calidad, con mejor
criterio para sugerir cambios en provecho de la calidad, con mejor capacidad de análisis y
observación del proceso de manufactura en en caso de productos y poder enmendar errores. El
uso de la calidad total conlleva ventajas, pudiendo citar como ejemplos las siguientes:
• Potencialmente alcanzable si hay decisión del más alto nivel.

• Mejora la relación del recurso humano con la dirección.
• Reduce los costos aumentando la productividad.
Principios de la Calidad
1. Cumplir con los requisitos. Para ello los directivos deben:

• Establecer los requisitos a cumplir

CALIDAD DE SOFTWARE
• Suministrar los medios necesarios

necesarios para que los empleados cumplan
• Motivar y estimular para que los requisitos sean cumplidos
2. La Calidad es la Prevención, no la verificación
3. El estándar de realización es el Cero Defectos
4. La medida de la Calidad es el precio por el incumplimiento
Factores
ctores esenciales para introducir el Control Total de Calidad
• Conciencia: en todos los niveles de la organización
• Trabajo en equipo: es el pilar de la Calidad, trabajar en mutua cooperación y sin
autoritarismo.
• Control y mejoramiento: mejorar sobre lo medido, ya que solo se puede mejorar lo
que se puede medir. Planes de mejora.
• Sistematización: en busca de la perfección de las actividades de la organización.
• Conocimiento y comparación de costos
• Evaluación: debe ser constante y retroalimentadora, a la vez
vez que debe ser imparcial
sobre los esfuerzos de los trabajadores en la actividad.
• Difusión: se debe comunicar qué se hace y qué pasa en la organización en todos los
niveles.
La calidad total en la organización de una empresa, debe ser el nervio y motor de

d la misma; si
de verdad la empresa desea alcanzar el éxito debe cimentarse en estas dos palabras. El
mensaje de la calidad total debe ser comunicado a tres audiencias que son complementarias
entre sí:
• Los Trabajadores.
• Los Proveedores; y,
• Los Clientes.
Los fundamentos de la calidad total son los siguientes:

• El objetivo básico: la competitividad
• El trabajo bien hecho.
• La Mejora continuada con la colaboración de todos: responsabilidad y compromiso
individual por la calidad.
• El trabajo en equipo es fundamental
fun para la mejora permanente
• Comunicación, información, participación y reconocimiento.
• Prevención del error y eliminación temprana del defecto.
• Fijación de objetivos de mejora.
• Seguimiento de resultados.
• Indicadores de gestión.
• Satisfacer las necesidades del cliente: calidad, precio, plazo.
Los obstáculos que impiden el avance de la calidad pueden ser:

• El hecho de que la dirección no defina lo que entiende por calidad.
• No se trata de hacer bien las cosas, sino de que el clientecliente opine igual y esté
satisfecho.
• Todos creen en su concepto, pocos en su importancia y son menos los que la
practican.
El Control de la Calidad
Se
e posesiona como una estrategia para asegurar el mejoramiento continuo de la calidad. Es
un programa para asegurar
segurar la continua
conti satisfacción de los clientes externos e internos
mediante el desarrollo permanente de la calidad del producto y sus servicios. Es un concepto
que involucra la orientación de la organización a la calidad manifestada en sus productos,
servicios,
vicios, desarrollo de su personal y contribución al bienestar general. El mejoramiento
continuo es una herramienta que en la actualidad es fundamental para todas las empresas
porque les permite renovar los procesos administrativos que ellos realizan, lo cual
cu hace que

CALIDAD DE SOFTWARE
las empresas estén en constante actualización; además, permite que las organizaciones sean
más eficientes y competitivas, fortalezas que le ayudarán a permanecer en el mercado. Para
la aplicación del mejoramiento es necesario que en la organización exista una buena
comunicación entre todos los órganos que la conforman, y también los empleados deben
estar bien compenetrados con la organización, porque ellos pueden ofrecer mucha
información valiosa para llevar a cabo de forma óptima el proceso
proceso de mejoramiento continuo.
La definición de una estrategia asegura que la organización está haciendo las cosas que debe
hacer para lograr sus objetivos. La definición de su sistema determina si está haciendo estas
cosas correctamente. La calidad de los procesos se mide por el grado de adecuación de estos
a lograr la satisfacción de sus clientes (internos o externos).
Es el proceso de alcanzar los objetivos de calidad durante las operaciones. Para el

efecto, se deberán desarrollar los siguientes pasos:
a) Elegir qué controlar.

b) Determinar las unidades de medición.
c) Establecer el sistema de medición.
d) Establecer los estándares de desempeño.
e) Medir el desempeño actual.
f) Interpretar la diferencia entre lo real y el estándar.
g) Tomar acción sobre la diferencia.
El término calidad se ha convertido en una de las palabras clave de nuestra sociedad,

alcanzando tal grado de relevancia que iguala e incluso supera en ocasiones al factor precio,
en cuanto a la importancia otorgada por el posible comprador de un producto o servicio.
Las necesidades de quienes compran nuestros productos o servicios no son estáticas, sino que
evolucionan de forma continua. Esto supone la permanente adaptación de todos nuestros
procesos productivos y comerciales
comerciales a dichas necesidades, si queremos seguir contando con
SU FIDELIDAD.
Pasos para poner en marcha el Control de Calidad
Cada uno de los conceptos de la estrategia del Control Total de Calidad conlleva muchas
actividades. Por lo tanto se hace necesario
necesario establecer un plano o programa cuyo desarrollo
asegure el éxito de su aplicación en la empresa. Un plan para poner en práctica el Control
Total de Calidad, podría contener las siguientes actividades:
COMPROMISO Y ORGANIZACIÓN.
1. Establecimiento del compromiso

compromiso de la alta dirección con la implementación del CTC y
con las actividades de los círculos de control de calidad. Debe establecerse el por que
de esta decisión. Para ello es básico conocer los conceptos básicos de CTC, sus
beneficios, la importancia del
del cliente, el valor del recurso humano, la necesidad de
optimizar recursos y tecnología, lo vital del ciclo de control y aspectos similares.
2. Organización de un comité directivo o de un consejo.
3. Designación de los miembros del comité de CTC.
4. Organización de e una oficina de CTC para los miembros del comité o consejo, así como
para la promoción CTC.
5. Designación del director de la oficina de CTC así como de los facilitadores de CTC.
Estos últimos son el apoyo metodológico para la implantación del CTC en toda la
organización.
PLANEACIÓN
1. Establecimiento de la política de implementación del CTC y del programa para

lograrlo. Esto debe hacerlo el comité o el consejo.

CALIDAD DE SOFTWARE
2. Visitas a otras empresas o países para visualizar la operación del CTC, por parte de la
alta dirección, los gerentes, así como del director de la oficina de CTC y de los
facilitadores.
3. Establecimiento de una plan adecuado a las condiciones de la empresa y de su
correspondiente calendario de implementación; esta actividad es responsabilidad del
director
ector de la oficina de CTC.
EDUCACIÓN Y ENTRENAMIENTO
1. Realización de eventos de educación, dirigidos a la alta dirección.

2. Realización de actividades educativas dirigidas a la gerencia, al director de la oficina
de CTC y a los facilitadores de CTC.
3. Preparación
ación del material educativo para la aplicación del CTC y de las 7 herramientas
básicas de control de calidad. El material deberá ser diseñado para directores,
gerencia media, staff y supervisores.
4. Puesta en práctica del programa de educación y entrenamiento
entrenamiento a cada nivel, según lo
programado. Esto incluye la aplicación de los conceptos aprendidos.
PRIMERAS ACCIONES
1. Una vez terminado el entrenamiento, "sacudida" de cada sección o departamento

para identificar, con ayuda de los subordinados de cada sector, sus fuerzas y
debilidades.
2. Diseño de un proyecto (uno fácil), como ejercicio de los casos de Ruta de Calidad (o
de mejoramiento del control de calidad) y de la utilización efectiva de los datos:
desarrollo de este con aplicación del ciclo de control (los ocho pasos de la ruta de
calidad). Repetición de este ejercicio para el siguiente aspecto de menor dificultad.
Cuando ya se esté familiarizado con el proceso, enfrentamiento con los proyectos
críticos o importantes para el mejoramiento.
3. Realización de eventos
eventos educativos para los supervisores, en aspectos relacionados con
los Círculos de Control de Calidad.
4. Promoción e instalación de Círculos de Control de Calidad piloto, voluntarios y con
supervisión también voluntaria, para practicar de nuevo los ocho pasos
paso de la Ruta de
la Calidad. Repetición de estas actividades hasta terminar con lo estipulado en el plan
y en el programa.
ADMINISTRACIÓN POR POLÍTICA Y ESTANDARIZACIÓN.
1. Preparación de un borrador de administración por políticas, por parte de la oficina de

d
CTC.
2. Obtención de la aprobación por la alta dirección y el consejo de CTC.
CALIDAD DE SOFTWARE
Introducción
El desarrollo de sistemas hoy en día ha tomado gran importancia en el mundo, siendo ésta
cada vez más creciente. Si una empresa de software pretende competir a nivel internacional,
es necesario que contemple seriamente la necesidad de realizar una CERTIFICACION
CERTIFIC DE
CALIDAD DEL SOFTWARE Y DEL SISTEMA. Muchos proyectos de sistemas presentan fallas
que impiden que el sistema funcione como era de esperarse o que sea utilizado en su
totalidad. Por ello, es necesario definir e impulsar líneas de acción tendientes a mejorar el
sistema producido. Dentro de estas líneas de acción, está la relacionada con el proceso mismo
del desarrollo del sistema, y como necesidad primordial, la de realizar una investigación que
permita conocer de primera mano el estado en que se encuentra
encuentra su proceso de desarrollo.
CALIDAD DE SOFTWARE
Diferenciaremos dos conceptos importantes como son:
• El control de calidad de sistemas está orientado a garantizar el funcionamiento de

los sistemas en explotación.
• El control de calidad de software está orientado a garantizar las características de
los programas que se están desarrollando.
La Ingeniería de Software concierne a teorías, métodos y herramientas para el desarrollo

profesional de productos. Un Sistema concierne a un conjunto de componentes
interrelacionados
dos trabajando conjuntamente para un fin común. El sistema puede incluir
software, dispositivos mecánicos y eléctricos, hardware, y ser operado por gente. Existen
varias organizaciones de estandarización internacional que realizan estándares y modelos de
ingeniería
ngeniería de software, esto con el fin de mejorar la Calidad del Software.
La Calidad
La ISO (International Standard Organization), define La Calidad como la ausencia de

deficiencias:
"Es la totalidad de aspectos y características de un producto o servicio
servicio que se refieren a su
capacidad para satisfacer necesidades dadas en la adecuación de sus objetivos'”.
El Instituto de Ingeniería de Software (SEI) en su modelo CMM (Capability Maturity Model)
define la calidad como:
• El grado en el cual un sistema, componente

componente o proceso cumple con los requisitos
especificados.
• El grado en el cual el sistema, componente o proceso cumple con las expectativas del
cliente o usuario.
• La calidad consiste en todos aquellos aspectos del producto que satisfacen las
necesidades del cliente y de ese modo proporcionan la satisfacción del producto.
La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad,

portabilidad, usabilidad, seguridad e integridad. La Calidad del Software es el conjunto de
cualidades
ualidades que lo caracterizan y que determinan su utilidad y existencia. La Calidad del
Software es mensurable y varía de un sistema a otro o de un programa a otro. Por ejemplo:
un software elaborado para el control de naves espaciales debe ser confiable ala nivel de "cero
fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad;
mientras que un producto de software para ser explotado durante un largo período (10 años o
más) necesita ser confiable, mantenible y flexible para
para disminuir los costos de mantenimiento
y perfeccionamiento durante el tiempo de explotación.
Aspectos de la Calidad
La Calidad del Software puede medirse después de elaborado el producto. Pero esto puede
resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por
lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control
cont
durante todas las etapas del ciclo de vida del software.
Objetivo de la Calidad en los Sistemas
El Objetivo que persigue la Calidad en los Sistemas está orientada a:
• Incrementar la productividad y satisfacción al trabajo de los profesionales afines al

campo de la computación.
• Mejorar la calidad del producto del software.
• Proveer técnicas aplicadas para automatizar el manejo de datos.

CALIDAD DE SOFTWARE
• Realizar una planeación eficaz de los sistemas.

• Documentar.
• Validar y controlar formalmente la calidad del trabajo realizado.
rea
• Cumplir con los objetivos de la organización en cuanto a productividad de sus
sistemas de cómputo.
Obtención de un Software de Calidad
La obtención
btención de un Software con Calidad implica la utilización de metodologías o
procedimientos estándares para el análisis, diseño, programación y prueba del software, que
permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad,
mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor
de desarrollo
lo como para el control de la Calidad del Software.
• El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del

software.
• El principio administrativo contempla las funciones de planificación y control del
desarrollo del software, así como la organización del ambiente o centro de ingeniería
de software.
• El principio ergonómico define la interfaz entre el usuario y el ambiente
automatizado. Para el aseguramiento de la calidad es necesario su control o
evaluación.
Control de la Calidad
El Control de la Calidad es realizar una observación constante acerca del cumplimiento de las
tareas que pueden ofrecer una calidad objetiva a la forma en cómo se está desarrollando un
proyecto de Ingeniería de Software. Es decir, una
una vigilancia permanente a todo el proceso de
desarrollo y ciclo de vida del software. Esta meta puede alcanzarse mediante frecuentes
inspecciones a las metodologías de trabajo y uso de herramientas, revisiones de prototipos y
evaluación exhaustiva de los productos
productos finales. El Control de la Calidad permite realizar las
rectificaciones pertinentes al desarrollo en cuanto éste empieza a desviarse de sus objetivos,
por lo tanto, de la calidad del trabajo. Estas rectificaciones son posibles gracias a una
retroalimentación
imentación de las etapas superiores, creado así un aprendizaje al observar las salidas
de cada etapa, hasta el producto final, y mejorar los procesos que dan origen al sistema.
En el Control de Calidad deben tenerse presentes los costos que esta involucra. Si se piensa
en las tareas que deben realizarse en este control, puede observase que es necesario llevar a
cabo tareas de búsqueda de problemas, evaluación, realimentación, rectificación, elaboración,
modificación y estudio de la documentación; entre otras
otra actividades.
Pero debe existir un compromiso, ya que un excesivo costo en el control de la calidad puede
hacer que este proceso se torne ineficiente. Pero, por otra parte, el mejoramiento de la
calidad implica reducir los costos ya que se tendría un cierto
cierto nivel de calidad ya asegurado.
Finalmente, y como consecuencia de la naturaleza del proceso de desarrollo de productos
software, el asegurar la calidad en las primeras etapas de este involucra que los costos del
control en las etapas posteriores tenderá
tenderá a disminuir al tener menos aspectos que controlar
pues, nuevamente, la calidad estaría asegurada en sus bases.
Control de Calidad del Software
Para controlar la Calidad del Software es necesario, definir los parámetros, indicadores o
criterios de medición.
ión. El software posee determinados índices mensurables que son las bases
para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados
los índices de calidad, debe establecerse el proceso de control, que requiere los siguientes
siguie
pasos:

CALIDAD DE SOFTWARE
1. Definir el software que va a ser controlado:

controlado: clasificación por tipo, esfera de
aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el
desarrollo del software.
2. Seleccionar una medida que pueda ser aplicada al objeto de de control.
control Para cada
clase de software es necesario definir los indicadores y sus magnitudes.
3. Crear o determinar los métodos de valoración de los indicadores: indicadores métodos
manuales, como cuestionarios o encuestas estándares para la medición de criterios
periciales
les y herramientas automatizadas para medir los criterios de cálculo.
4. Definir las regulaciones organizativas para realizar el control:
control quiénes participan
en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y
elaborados, etc.
Indicadores para diferenciar los productos de calidad de los que carecen de ella:
• Ell acercamiento a cero defectos.

• El cumplimiento de los requisitos intrínsecos y expresos.
• La satisfacción del cliente
La Calidad del Software debe ser una disciplina más dentro de la Ingeniería del software. El
principal instrumento para garantizar la calidad de las aplicaciones sigue siendo el Plan de
Calidad. El plan se basa en unas normas o estándares genéricos y en unos procedimientos
procedi
particulares.
Las normas, directivas, modelos y estándares son básicamente las siguientes:
• Familia de normas ISO 9000 y en especial, la ISO 9001 y la ISO 9000-3.2:1996

9000
Quality Management and Quality Assurance Standards
• ISO 8402: 1994
• IEEE 730/1984, Standard for Software Quality Assurance Plans
• IEEE Std 1028: 1989, IEEE Standard for Software Reviews and Audits
• CMM. Capability Maturity Model
• ISO/IEC JTC1 15504. SPICE. Software Process Improvement and Capability
Determination.
• Modelo de EFQM. Modelo de la Fundación Europea de Gestión de Calidad
Los procedimientos pueden variar en cada organización, pero lo importante es que estén
escritos, personalizados, adaptados a los procesos de la organización y, lo que es más
importante, que se cumplan. La Calidad del Software debe implementarse a lo largo de todo
el ciclo de vida, debe correr paralela desde la planificación del producto hasta la fase de
producción del mismo.
Capacidades del Software
Las capacidades importantes para un producto de softwaresoftware desde el punto de vista del
usuario, así como los factores que determinan la calidad de cada una de las capacidades son:
• Capacidad de operación con los factores de corrección, facilidad, eficiencia, integridad
y facilidad de uso.
• Capacidad para ser modificado o de revisión con los factores de flexibilidad, facilidad
de prueba y facilidad de mantenimiento.
• Capacidad de transición o de adaptación a otros entornos con los factores de
transportabilidad, capacidad de reutilización y de interoperación.
Calidad
lidad Total en el Proceso de Desarrollo del Sistema
Para alcanzar la "Calidad Total", es necesaria la satisfacción por parte de los elementos que
intervienen en el proceso:

CALIDAD DE SOFTWARE
• La satisfacción de la alta dirección

• La satisfacción del personal involucrado en el desarrollo del sistema
• La satisfacción del usuario final
La aplicación del control de calidad de sistemas no es solamente al sistema en sí, ésta

conforma la última parte de la evaluación.
Elementos para el Proceso de Sistemas
Son tres los elementos que

que integran el proceso de sistemas, los cuales por su importancia
deben de considerarse para el mejor control de calidad y realización de los sistemas, estos
son:
1. Gente
2. Herramientas (Software y Hardware)
3. Tiempo disponible
Debe contarse con la gente adecuada, que tenga la suficiente capacidad para realizar el
trabajo, las herramientas de trabajo deben ser confiables, no limitadas y debe tomarse en
cuenta cuanto tiempo se dispone para la elaboración del sistema.
Componentes para la Calidad Total
• Claridad
• Involucración
• Planeamiento
• Estándares
• Entrenamiento
• Experiencia
• Controles
• Documentación
• Soporte
• Finalización
Claridad
La definición de lo que se tiene que hacer o lo que el usuario necesita, debe ser clara para
todos los responsables del proyecto,
proyecto, esto con el fin de establecer reglas a seguir.
Involucración
Es necesario revisar cada etapa del proyecto. Para cada una de ellas es importante dejar en
claro si vale la pena continuar o no, si hay limitaciones o restricciones que afecten o impidan
el buen funcionamiento del proyecto y si se está dando el cubrimiento adecuado a todos los
requerimientos y funciones, divisiones o departamentos que están involucrados en la
realización del proyecto.
Planeamiento
En la planificación intervienen tanto los usuarios
usuarios como el personal que desarrolle el proyecto.
Debe planearse el grado de integración que se requiere en las diferentes áreas de la
organización, para interpretar necesidades o requerimientos satisfactorios con el objeto de
llegar a acuerdos en caso dede imprevistos en asuntos tan simples como el método mediante el
cual vamos a poner a trabajar alguna etapa o actividad en el proyecto.
Estándares
Tiene que tomarse en cuenta la forma mediante la cual vamos a trabajar desde el punto de
vista tecnológico, yaa que es necesario tener presente la definición de diversos factores que
afectarían la realización del proyecto, como son:

CALIDAD DE SOFTWARE
• Lenguaje de programación
• Manejo de librerías
• Código
• Instrucciones
• Comentarios
• Administración de backups
• Administración de archivos
• Periodicidad
riodicidad de revisiones
• Documentación
Debe quedar clara su definición, los elementos que los deben integrar, así como su
estandarización. Sin una estandarización el proyecto se vendría abajo.
Entrenamiento
El entrenamiento es un factor determinante para la realización de un proyecto, ya que
mediante él se obtienen los conocimientos y habilidades que se aplicarán en el proyecto.
Experiencia
El contar con mucha o poca experiencia, determina el tiempo de desarrollo del sistema así
como la calidad del trabajo que realice (oportunidad - calidad).
Controles
Los controles que se establezcan deben realizarse con alguna periodicidad. Primeramente
debe verse el avance del proyecto; el cumplimiento de los requerimientos del cliente; el
seguimiento y las normas
normas de seguridad y de auditoríaa; la involucración de las personas clave
para el proyecto; el funcionamiento de la aplicación; del desarrollo con el usuario y un punto
importante es la mutua satisfacción entre de la gente que realiza el proyecto con el usuario.
usuar
En este caso puede contarse con un Calendario de Entrega donde contenga los puntos
anteriormente mencionados, así como contar con Bitácoras que respalden las reuniones que
se tengan con los usuarios y los acuerdos a los que hayan llegado ambas partes.
Documentación
Es importante que la documentación que se genere debe ser clara y útil en cuanto al sistema,
ya sean los programas, las tareas del usuario y sus procedimientos, el manejo de la aplicación
y producción y los cuidados con respecto a back-ups,
back ayudas y soporte requerido, la bitácora
de historia respecto a fallas, mejoras, arreglos, etc., contribuyen a una mejor utilización del
sistema, es decir, a una mayor calidad en su operación. Manuales de usuario, técnico y de
operación.
Soporte
Es indispensable
nsable tener claro quién nos puede apoyar en las áreas técnica, de análisis, en el
área usuaria, ya sea en la instalación, en el área ejecutiva o en algún otro aspecto, ya que las
aplicaciones en los proyectos de sistemas enfrentan siempre necesidades críticas
crít de soporte.
Finalización
La finalización del proyecto de un sistema es una de las labores más importantes en el
desarrollo del mismo, de igual manera que en cada etapa. En la finalización del proyecto es
necesario considerar cinco puntos vitales:
• La revisión de todos los pasos realizados y de las etapas incluidas en el proceso total;
• Elaboración del proceso en forma integral;
• Calidad hecha en cada uno de los pasos o etapas del proyecto;
• La atención a los requerimientos del usuario en términos de hacer hace todo lo que él
quiera, o más;
• Y, por supuesto, la satisfacción de nuestro usuario o cliente que, en últimas, es el
reconocimiento a la labor bien realizada y de alta calidad.

CALIDAD DE SOFTWARE
Cuando se desarrolle un sistema o aplicación y se instale, debe asegurarse de hacerlo de tal

manera que lo que se entregue esté completo, sea oportuno, no tenga errores, sea confiable,
útil y estable.
Administración de la Calidad
La Administración de la Calidad cuenta con dos niveles de trabajo:
El nivel de entidad u organización.

organización Donde se trata de crear y gestionar una
infraestructura que fomente la calidad de los productos software mediante la adecuación y
mejora de las actividades y procesos involucrados en su producción e, incluso, en su
comercialización y en la interacción con
co los clientes.
El nivel del proyecto.. Donde las guías que la infraestructura organizativa prevé para las
distintas actividades y mantenimiento del software deben ser adaptadas a las características
concretas del proyecto y de su entorno para ser aplicadas
aplicadas a la práctica. Dentro del primer
nivel de acción, la gestión de la calidad en organizaciones de software ha seguido dos líneas
que pueden ser complementarias entre sí: Por una parte, se ha seguido la línea marcada por
las entidades internacionales de estandarización
estandarización para todas las organizaciones de producción
o servicios. Principalmente se han impuesto en la práctica las directrices marcadas por ISO
(Organization for International Standardization) a través de unas normas ISO 9000 para la
gestión de calidad.
d. En el caso del software es principalmente aplicable la norma ISO 9001. El
sector de software difiere por la naturaleza del producto tanto del resto de sectores
productivos que ha sido necesario crear una guía específica para su aplicación a este sector:
ISO 9000-3.3. El mundo del software ha creado sus propias líneas de trabajo en la gestión de la
calidad, trabaja sobre los procesos de producción como medio para asegurar la calidad del
producto software. Por ejemplo, el SEI (Software Engineering Institute), proponiendo un
modelo de clasificación y mejora de los procesos empleados
empleados por las organizaciones de
software denominado CMM. La Calidad del Software se diseña conjuntamente con el sistema,
nunca al final. A mayor calidad, mayores son los costos, pero mayores también los beneficios
obtenidos en la fase del mantenimiento del software.
software. Este costo hay que considerarlo dentro
de todo el ciclo de vida del proyecto. El aseguramiento de la Calidad de Software engloba un
enfoque de gestión de calidad, tecnología de ingeniería de software efectiva (métricas y
herramientas), revisiones técnicas
técnicas formales que se aplican durante el proceso del software,
una estrategia de prueba multiescalada, el control de la documentación del software y de los
cambios realizados, un procedimiento que asegure un ajuste a los estándares de desarrollo
del software
are (cuando sea posible) y mecanismos de medición y de generación de informes.
La Prueba del Software
Se pueden realizar inspecciones para cada módulo o pequeño grupo de módulos que
conformen un sistema. Al limitar el centro de atención de la RTF la probabilidad
prob de descubrir
errores es mayor.
Calidad en el Diseño
Aquí se plantean características definidas para la realización del producto software que
deberán cumplirse posteriormente. La calidad se basa en definir un listado de especificaciones
a seguir. Involucra descripción de los procesos, tareas y responsabilidades de los equipos de
desarrollo. En esta etapa la calidad aumenta en la medida en que se realiza una alta
especificación de los procesos y se propone una estrecha tolerancia a la modificación,
estableciendo los métodos correctivos a las desviaciones ocurridas. Esta es la medida de la
calidad apreciada por los usuarios finales del entendimiento del producto software. Estas
apreciaciones de calidad hacia un determinado producto elevarán el nivel de confianza para la
organización desarrolladora, lo que puede elevar su posición en el mercado.

CALIDAD DE SOFTWARE
MODELOS Y ESTÁNDARES DE CALIDAD DE SOFTWARE
LOS CINCO MODELOS MÁS ACREDITADOS EN

E CALIDAD DE SOFTWARE
Introducción
La estandarización es toda actividad documentada que norma el comportamiento de un grupo

de personas. Los estándares nos dan los medios para que todos los procesos se realicen
siempre de la misma forma, mientras nos surjan ideas para mejorarlos. Son nuestra guía
g para
la productividad y la calidad.
Expectativas de los estándares:

• Mejora de procesos de software acorde a los objetivos estratégicos
• Mejora de los productos
• Protección del cliente o usuario
• Protección de la organización (cultura de la organización y mejora continua)
Existen varias organizaciones de estandarización internacional, algunas son regionales

mientras que otras son globales. Las últimas están relacionadas con la ONU o son
independientes, como por ejemplo la International Telecommunication Union
Union (ITU).
La International Electrotechnical Commission (IEC) que fue fundada en el año 1906 para
definir estándares en eléctrica y electrónica, mientras que la Internacional Organization for
Standardization (ISO) fue creada en 1947 para abarcar otros temas. temas. Ambas tienen por
objetivo facilitar el intercambio de bienes y servicios a nivel internacional, entre otras. En
1987, ISO e IEC decidieron formar el Joint Technical Commit (JTC), cuyo objetivo es elaborar
estándares para la tecnología de información Information
Information Technology (IT). Organizaciones
como la ISO, BOOTSTRAP, entre otras se han dedicado a crear modelos para mejorar la
Calidad del Software, entre ellos tenemos:
• ISO 9000
• CMM (Estados Unidos)
• Tick It (Inglaterra)
• Bootstrap (Europa)
• ISO/SPICE (Australia)
La Norma ISO 9000
La Organización Internacional para la Estandarización (ISO) fue fundada el 23 de febrero de

1947 con el objetivo de crear una norma internacional de calidad. El Comité Técnico ISO/TC
176 para Aseguramiento de la Calidad fue el encargado de crear el estándar ISO 9000.
El objetivo del estándar es desarrollar un código mínimo que contenga prácticas de

administración para garantizar el Aseguramiento y Administración de la Calidad, es decir, qué
hacer para responder a los requerimientos
requerimientos de un mercado cada vez más competitivo y cómo
deben responder los proveedores y compradores respecto a la calidad de los bienes o
servicios intercambiados. Para ello establece una serie de guías para la selección y uso del
estándar deseado, así como
como aclara conceptos en cuanto a la calidad y las interrelaciones que
se establecen.

CALIDAD DE SOFTWARE
Estructura General
De forma general la norma se divide en 4 guías o modelos fundamentales:
• ISO 9001 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad en el diseño,

desarrollo, producción, instalación y servicio.
• ISO 9002 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad para la
producción, instalación y servicio.
• ISO 9003 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad para la
inspección
cción final y pruebas.
• ISO 9004 Elementos para la Administración y el Sistema de Calidad. Guía para el
Sistema de Aseguramiento de la Calidad.
Además, existen otras normas y entre ellas las más relevantes son:
• ISO 9000-1
1 Guía para la selección de la norma a usar.
• ISO 8402 Recopilación de definiciones. Vocabulario.
• ISO 9000-3
3 Estándares de Administración y Aseguramiento de la Calidad.
De forma general los requerimientos fundamentales de ISO 9000 son:
• Escribir un manual de calidad, describiendo el Sistema

Sistema de Calidad en alto nivel.
• Escribir documentos en forma de procedimientos que describan cómo debe hacerse el
trabajo en la organización.
• Crear un sistema para controlar la distribución y reedición de documentos.
• Diseño e implantación de un sistema de acciones acciones preventivas y correctivas para
prevenir la ocurrencia de problemas.
• Identificar las necesidades en cuanto a entrenamiento en la organización.
• Determinar las medidas y equipos para realizar las pruebas.
• Capacitar al personal de la organización en la operación del Sistema de Calidad.
• Planificar y llevar a cabo auditorias de calidad internas.
• Tener en cuenta los requerimientos del estándar con los que no cumple la
organización.
Los factores que determinan el modelo a elegir son:
a) La complejidad del proceso

proceso de diseño. Se refiere a la dificultad para diseñar el producto o
servicio cuando éste no ha sido diseñado.
b) La madurez del diseño. Se proyecta hacia el conocimiento y aprobación del diseño total,
ya sea por las pruebas de desempeño o por la experiencia en el campo.
c) La complejidad del proceso de producción. Está relacionado con la capacidad del proceso
de producción, las necesidades de desarrollo del nuevo proceso, las variaciones que se
requieren y el impacto en el desempeño del producto o servicio.
se
d) Las características del producto o servicio. Depende de la complejidad del producto o
servicio, del número de características interrelacionadas y de su influencia en el
desempeño.
e) La seguridad del producto o servicio. Relacionado con el riesgo de ocurrencia
ocurrencia de fallas y el
impacto de éstas.
El Modelo CMM
A principios de los años 80’s el Departamento de Defensa de los Estados Unidos enfocó sus
tareas a la revisión de los problemas del software y a su mejoramiento. Se
S creó el Instituto de
Ingeniería de Software (SEI) a finales de 1984. Como parte de su trabajo, el Instituto se dio a
la tarea de desarrollar el Modelo de Madurez del Proceso de Software y para 1986 se
comenzó el Proyecto de Evaluación de la Capacidad del Software. Después de varios años de

CALIDAD DE SOFTWARE
realizar cuestionarios, evaluaciones, consulta e investigación, junto a otras organizaciones, en

1991 SEI produce el Modelo de Capacidad y Madurez del Software.
El Modelo de Madurez y Capacidad del Proceso de Software (CMM) ayuda a que las
organizacioness para producir de manera consistente y predecible productos de calidad
superior. La capacidad del proceso es la habilidad inherente para producir los resultados
planeados. El principal objetivo de un proceso de software maduro es el de producir productos
de calidad que cumplan los requerimientos del usuario.
Cuando se habla de madurez se entiende como el crecimiento alcanzado en la capacidad del

proceso de software y que se considera como una actividad a largo plazo. En una
organización de software inmadura,
inmadura, el proceso de software es generalmente improvisado, no
existen planes rigurosos, se enfocan en resolver las crisis que se le presentan, carecen de
bases objetivas para enjuiciar la calidad de los productos o para resolver los problemas. Por lo
contrario
o cuando la organización alcanza cierto grado de madurez posee una gran habilidad
para administrar el proceso de desarrollo y mantenimiento del software, se hacen pruebas y
análisis de costo-beneficio
beneficio para mejorar el proceso, el administrador monitorea la calidad del
producto y la satisfacción del cliente, se llevan registros y todos los integrantes están
involucrados.
La madurez del proceso de software esta dada cuando un proceso en específico es

explícitamente definido, administrado, medido, controlado y es efectivo. El ciclo Shewhart
propone las bases para el trabajo de mejoramiento del proceso. Este consta de 4 pasos que
se repiten en forma de ciclo hasta que la implantación produce los resultados esperados y los
cambios pasan a ser permanentes.
Los pasos son:
1. Planear
a. Definir el problema
b. Establecer los objetivos a mejorar
2. Ejecutar
a. Identificar las posibles causas de problemas
b. Establecer las bases
c. Probar los cambios
3. Revisar
a. Recolectar los datos
b. Evaluar los datos
4. Actuar
a. Implementar los cambios
b. Determinar la efectividad
CMM es un modelo descriptivo en el sentido que describe los atributos esenciales que se
espera caractericen una organización dentro de un nivel de madurez en particular. Es un
modelo normativo ya que las prácticas detalladas caracterizan el tipo t normal de
comportamiento que se espera de una organización que realiza proyectos a gran escala.
No es prescriptivo ya que no dice a la organización como mejorar.
Estructura del modelo
El modelo consta de 5 niveles, diseñados de forma que los inferiores proveen unos fuertes
cimientos incrementados de manera progresiva sobre los que se construyen los niveles
superiores.
Estas 5 etapas de desarrollo son referidas como niveles de madurez y en cada una la
organización alcanza una capacidad en el proceso
p superior.
Los 5 niveles del modelo son:

CALIDAD DE SOFTWARE
1. Inicial: el proceso de software es un proceso improvisado y caótico. Pocos procesos

están definidos y el éxito que se pueda obtener depende de las habilidades,
conocimientos y motivaciones del personal. No existen calendarios ni estimados de
costos y las funcionalidades y calidad del producto son impredecibles. No existe un
ambiente estable para el desarrollo y mantenimiento del software. El proceso del
software es impredecible por el continuo cambio o modificación
modificación a medida que avanza
el trabajo.
2. Repetible: se establecen procedimientos de administración del proceso básico para
determinar costos, calendarios y funcionalidades. Se establecen las políticas para la
administración del proceso y los procedimientos de implantación. El proceso se basa
en repetir éxitos anteriores en proyectos de similares características, por lo que los
mayores riesgos se presentan cuando se enfrentan a nuevos proyectos. Se exhiben
problemas de calidad y carecen de una adecuada estructura
estructura para mejorarla.
3. Definido: el proceso de software para las actividades administrativas y técnicas está
documentado, homogeneizado e integrado en un proceso de software estándar
dentro de la organización, que ayudará a obtener un desempeño más efectivo. El
grupo que trabaja en el proceso enfoca y guía sus esfuerzos al mejoramiento de su
desarrollo, facilita la introducción de técnicas y métodos e informa a la administración
del estado del proceso. La capacidad del proceso está basada en una amplia
comprensión
nsión común dentro de la organización de las actividades, roles y
responsabilidades definidas en el desarrollo de software.
4. Administrativo:
Administrativo se recolectan medidas detalladas del proceso de software y de la
calidad del producto. Ambos son cuantitativamente entendidos
entendidos y controlados. El ciclo
de Shewhart es constantemente utilizado para planear, implementar y registrar las
mejoras al proceso. Este nivel de capacidad permite a la organización predecir las
tendencias en la calidad del producto dentro de los límites
límites establecidos y tomar las
acciones necesarias en caso que sean excedidos. Los productos de dicha categoría
son predeciblemente de alta calidad.
5. Optimización:: el mejoramiento continuo del proceso es garantizado por la
retroalimentación cuantitativa y desdedesde las pruebas de técnicas y herramientas
innovadoras. La organización tiene los medios para identificar los puntos débiles y
conocer como fortalecerlos. Su actividad clave es el análisis de las causas de defectos
y su prevención.
El Modelo Tick IT
El Departamento
artamento de Comercio e Industria del Reino Unido (DTI: Department of Trade and
Industry) creó el esquema Tick IT. Los objetivos primordiales de éste fueron, además de
desarrollar un sistema de certificación aceptable en el mercado, estimular a los
desarrolladores
lladores de software a implementar sistemas de calidad, dando la dirección y guías
necesarias para tal efecto. Aunque el proyecto original estuvo a cargo del DTI1, la
responsabilidad actual por el esquema Tick IT se pasó a DISC, que es una oficina dependiente
dependie
de British Standards Institution (BSI) Standards Division, siendo esta última la única autoridad
en el Reino Unido para publicar estándares.
Ciclo de Vida del Software
Un sistema de calidad típico Tick IT deberá contener los elementos que se enlistan a
continuación:
• Elaboración de propuestas y revisión de contratos asegurando que todos los

requerimientos estén bien especificados y de que la organización tiene la capacidad
para cumplirlos.
• Análisis y especificación
pecificación de los requerimientos del sistema asegurando que sean
revisados y acordados con el cliente.

CALIDAD DE SOFTWARE
• Planeación, control y monitoreo del avance del desarrollo respecto al plan

comunicando a todas las partes afectadas y que avise oportunamente de problemas
proble
potenciales.
• Planeación de la calidad del proyecto, especificando las inspecciones, revisiones y
pruebas requeridas durante el desarrollo.
• Inspecciones de los productos contra estándares y requerimientos aplicables y las
acciones correctivas correspondientes.
• Diseño de primer nivel identificando los componentes principales y los requerimientos
que satisfacen.
• Diseño detallado de todos los componentes e interfaces, construcción, y prueba de los
mismos verificando que satisfagan la especificación.
especificació
• Integración, pruebas e inspecciones del sistema, demostrando que el sistema
integrado funciona correctamente y satisface su especificación.
• Identificar, segregar, investigar y corregir productos no conformes.
• Auditorias, pruebas e inspecciones de aceptación
aceptación del sistema demostrando al cliente
que el sistema satisface los requerimientos.
• Almacenamiento, replicación, envío e instalación, asegurando la integridad y
seguridad de los productos, así como el cumplimiento de los compromisos adquiridos
con el cliente.
• Puesta en marcha y liberación del producto para disponibilidad del cliente.
• Entrenamiento a usuarios en el uso del sistema de tal manera que pueda operarlo y
beneficiarse completamente del mismo con la mínima intervención del proveedor.
• Mantenimiento o sustitución del sistema, asegurando que se continúa operando en
conformidad con los requerimientos del cliente o usuario.
• Soporte a clientes de acuerdo a lo especificado en el contrato.
Soporte y Aseguramiento de Calidad
• Establecer políticas y objetivos

objetivos de calidad generales de la organización que sirvan
para alinearla en todas sus actividades, procedimientos y políticas específicas.
• Implantar y mantener un sistema de aseguramiento de calidad.
• Auditorias, revisiones y acciones correctivas al sistema de calidad
calidad que aseguren que el
sistema cumple con los requerimientos, es utilizado y que es efectivo en el logro de
resultados.
• Definir, recolectar y analizar datos de calidad para evaluar la efectividad del sistema
de calidad e identificar mejoras potenciales.
potenciales
• Administración de la organización y los proyectos de tal forma que facilite los
resultados de calidad.
• Administración de la configuración que identifique y controle, de manera continua, las
partes constituyentes y sus versiones, de cada instancia de un sistema
sistema o subsistema.
• Respaldos, seguridad y almacenamiento que protejan contra cualquier pérdida o
corrupción.
• Sistema de control de registros y documentación para todas las actividades de
aseguramiento de calidad, de los proyectos y de soporte, incluyendo procedimientos y
registros.
• Especificación y control del proceso de desarrollo incluyendo técnicas, prácticas,
convenciones, estándares, mediciones y estadísticas.
• Proceso de compras, incluyendo identificación, selección, adquisición y aceptación que
asegure
ure que los bienes y servicios adquiridos sean como se requiere y de calidad
aceptable.
• Control de productos incluidos, equipo y herramientas utilizadas: Hardware o
Software, adquiridos o suministrados por el cliente, incluyendo utilización,
configuración, seguridad.
• Entrenamiento, reclutamiento y desarrollo de personal que asegure su competencia y
motivación, y disminuya su rotación.

CALIDAD DE SOFTWARE
El Modelo BOOTSTRAP
El Instituto Bootstrap es una organización no lucrativa dedicada a la mejora continua del

modelo de calidad
lidad de software llamado BOOTSTRAP, también tiene como propósito ayudar a
la industria europea del software para mejorar su competitividad. Bootstrap es un método
para analizar, rediseñar y mejorar los procesos de negocio del desarrollo de software.
Este se compone de: un modelo, un proceso de evaluación, una base de datos de soporte, un
proceso de mejora y los instrumentos de evaluación. Su enfoque es evaluar el proceso, no el
producto. Para eso se definen un conjunto de características para los procesos,
procesos provee un
análisis cuantitativo, produce vistas analíticas, hace evidente fortalezas y debilidades,
identifica áreas de mejora, provee recomendaciones y sugiere un plan de implementación. El
modelo define el paradigma Organización-Metodología-
Organización Tecnología que se usa en Bootstrap
para los niveles de evaluación y agrupación de resultados.El modelo Bootstrap se basa en
evaluar las unidades de producción de software de la organización, a través de sus proyectos
para hacer un cambio a toda la organización. Dentro
Dentro de este proceso, hay cuatro etapas
principales: preparación, ejecución de la evaluación, determinación del nivel de madurez y
capacidades, y la presentación de resultados de la evaluación.
En la etapa de preparación se realizan las siguientes tareas:
1. un entrenamiento inicial para tener claros los objetivos

2. se seleccionan los proyectos a ser evaluados para obtener la mejor cobertura de la
UPS
3. se define el personal de evaluación para minimizar la subjetividad
4. se define el personal a ser evaluado para obtener la mejor cobertura de los roles
involucrados en los proyectos seleccionados y
5. se hace el acuerdo de confidencialidad.
En la etapa de ejecución,
ejecución las tareas son:
1. una
na breve reunión de apertura, para obtener un enfoque colaborativo con el personal
a ser entrevistado;
2. el llenado de los cuestionarios con características generales de la UPS;
3. el llenado de los cuestionarios del proyecto elegido, incluyendo la evaluación de cómo
el proceso de producción es aplicado;
4. revisión preliminar de la evaluación, y
5. reunión final, con el enfoque de presentar los resultados de la evaluación y obtener el
consenso para poder pasar a la fase de mejoras.
En la etapa de determinar el nivel de madurez y capacidades,

capacidades, es donde se califica cada
pregunta con uno de 5 valores posibles: nulo, débil, regular, extenso o no aplica. Para cada
atributo clave se obtiene un nivel de madurez, aplicando un algoritmo numérico, dando como
resultado uno de estos niveles: 1-inicial,
1 2-repetible, 3-definido,
definido, 4-administrado
4 o 5-
optimizado. Estos niveles de madurez están subdivididos en cuatro, de forma que se obtenga
una calificación más exacta. Los procesos de organización y metodología se califican de 1 a 5,
mientras que el de tecnología
tecnolog se califica sólo con dos niveles A o B.
Como resultado de la evaluación,

evaluación, la organización recibe 2 reportes, uno con los resultados
de la evaluación de la UPS y otro con los resultados del proyecto evaluado. El correspondiente
a la UPS contiene información
información como: un resumen ejecutivo, los objetivos de la UPS, los
puntos débiles y fuertes, un plan de acción recomendado, etc. El reporte del proyecto
contiene: comentarios del proyecto actual detallando lo referente a la organización,
metodología y tecnología,
tecnología, los niveles de madurez para el proyecto, el plan de acción
recomendado, etc.

CALIDAD DE SOFTWARE
Uso de las Bases de Datos de Soporte. Una de las características principales de Bootstrap
es la base de datos con que cuenta para hacer análisis. Con esto se fundamenta el plan de
mejoras, se pueden medir las adaptaciones a la metodología, se puede comparar contra la
industria y se pueden establecer objetivos basándose en la competencia.
Proceso de Mejora
Otra parte importante de la metodología de Bootstrap, es el plan de mejora que sugiere. El
proceso para obtener el plan de mejora es, Primero evaluar las necesidades de la organización
tomando en cuenta las mejoras deseadas e indicadores sobre calidad del producto y servicio,
tiempo de desarrollo, costos y riesgos del producto
producto y del proyecto. Enseguida hacer una
revisión y análisis de resultados de la evaluación, tomando en cuenta las fortalezas y
debilidades detectadas. Después definir las capacidades a mejorar, considerando un período
entre 18 y 24 meses. Enseguida, definir
definir las prioridades de acuerdo a un análisis de impactos.
Finalmente sobre la base de las actividades definidas, modificar la organización y
responsabilidades para iniciar el cambio, estableciendo un marco de tiempos para su
desarrollo y evaluación.
El Modelo ISO/SPICE
Software Process Improvement and Capability Determination. La Organización Internacional

para la Estandarización (ISO) creó el grupo de trabajo WG 10 y le encomendó el desarrollo del
estándar internacional de Valuación de Procesos de Software. El grupo de trabajo (Working
Group) WG 10, empezó a trabajar en enero de 1993 bajo la dirección de Alec Dorling y Peter
Simms,s, y decidieron crear el proyecto SPICE Software Process Improvement and Capability
Determination; la E de SPICE correspondía, originalmente, a "evaluation" y fue cambiado
porque en algunos idiomas se traducía equivocadamente. Una de las características
sobresalientes
bresalientes de este proyecto de estandarización es que incluyó un periodo de pruebas del
estándar de 2 años. Es decir, antes de ser publicado como estándar se había estado ajustando
por la práctica.
Arquitectura del Modelo

El modelo es tridimensional: la
l primera dimensión es funcional (procesos
procesos), la segunda de
capacidades (niveles),
), y la tercera de adecuación o efectividad (calificaciones
(calificaciones).
La dimensión PROCESO:
PROCESO
Está organizada jerárquicamente de la siguiente manera: CATEGORÍA DE PROCESOS, que
agrupan procesos
rocesos comunes; PROCESOS, que logran propósitos técnicos; PRÁCTICAS
BÁSICAS, operaciones que conforman un proceso. Las categorías definidas son: Cliente-
Cliente
Proveedor, Ingeniería, Proyecto, Organización y Soporte.
La dimensión CAPACIDAD:
CAPACIDAD
Está organizada ordinalmente
nalmente en niveles de capacidad y se han definido cinco niveles. En la
versión 1.0 éstosestos niveles son: Desempeño informal, Planeación y seguimiento bien
definido, Cuantitativamente controlado, Mejora continua. Está en etapa de instrumentación
una versión 2.0.
La tercera dimensión es la CALIFICACIÓN:

El juicio mismo: ¿qué calificación le doy a este proceso en este atributo de capacidad?. Las
escalas que se manejan son discretas de tipo: 0 = No adecuado, 1 = Parcialmente adecuado,
2 = Muy Adecuado, 3 = Totalmente Adecuado.
Los Elementos de Evaluación
Marco de Valor
El Modelo ISO/SPICE tiene un marco de valor explícito. En la dimensión funcional o de
proceso: las "mejores prácticas". En la dimensión de capacidad: los atributos de proceso o

CALIDAD DE SOFTWARE
prácticas genéricas
éricas que incrementarán la capacidad del proceso. Este es uno de los
componentes más valiosos del estándar internacional.
Evidencia
La evidencia para la evaluación serán los productos producidos por las prácticas base. Éste es
un enfoque de efectividad… "por sus frutos los conoceréis…". Cada producto tipo ha sido
catalogado y sus características de calidad definidas. Este es otro elemento filosófico
fundamental de ISO/SPICE: no es un modelo nominalista.
Recurrencia
Por último el elemento recurrencia, para fundamentar un juicio o evaluación vendrá dada por
la selección de instancias de proyectos o productos representativas, a juicio del Evaluador, de
las capacidades reales del proceso de software. Conceptualmente el modelo
modelo ISO/SPICE es un
modelo inductivo en su parte funcional: de característica a producto, de producto a práctica, y
de práctica a proceso. En su parte de capacidades es un modelo evolutivo. Es, en general, un
modelo realista: va a ver los productos, es decir,
decir, la efectividad de los procesos no lo que está
escrito en algún manual de calidad o de procesos.
EL MODELO MC-CALL
Introducción
El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el
usuario puede contemplar la calidad de un producto, basándose en once factores de calidad
organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios:
Puntos
De Vista Factor Criterios
o Ejes
• Facilidad de operación: Atributos del software que determinan la
facilidad de operación del software.
Facilidad de uso
• Facilidad de comunicación: Atributos del software que proporcionan

entradas y salidas fácilmente asimilables.
• Facilidad de aprendizaje: Atributos del software que facilitan la
familiarización inicial del usuario con el software y la transición del modo
OPERACIÓN DEL PRODUCTO
actual de operación.
• Formación: El grado en que el software ayuda para permitir que nuevos
usuarios apliquen el sistema.
• Control de accesos. Atributos del software que proporcionan control de
Integridad
acceso al software y los datos que maneja.

• Facilidad de auditoría: Atributos del software que facilitan la auditoría de
los accesos al software.
• Seguridad: La disponibilidad de mecanismos que controlen o protejan
loss programas o los datos.
• Completitud: Atributos del software que proporcionan la implementación
completa de todas las funciones requeridas.
Corrección
• Consistencia: Atributos del software que proporcionan uniformidad en

las técnicas y notaciones de diseño e implementación.
• Trazabilidad o rastreabilidad: Atributos del software que proporcionan
una traza desde los requisitos a la implementación con respecto a un
entorno operativo concreto.

CALIDAD DE SOFTWARE
• Precisión: Atributos del software que proporcionan el grado de precisión

requerido en los cálculos y los resultados.
OPERACIÓN DEL PRODUCTO
• Consistencia.
Tolerancia a fallos: Atributos del software que posibilitan la continuidad
Fiabilidad
•
del funcionamiento bajo condiciones no usuales.
• Modularidad: Atributos del software que proporcionan una estructura de
módulos altamente independientes.
• Simplicidad: Atributos del software que posibilitan la implementación de
funciones de la forma más comprensible posible.
• Exactitud: La precisión de los cálculos y del control.
• Eficiencia en ejecución: Atributos del software que minimizan el tiempo
Eficiencia
de procesamiento.
• Eficiencia en almacenamiento: Atributos del software que minimizan el
espacio de almacenamiento necesario.
• Modularidad.
mantenimiento
Simplicidad.
Facilidad de
•
• Consistencia.
• Concisión: Atributos del software que posibilitan la implementación de
una función con la menor cantidad de códigos posible.
REVISION DEL PRODUCTO
• Auto descripción: Atributos del software que proporcionan explicaciones

sobre la implementación de las funciones.
• Modularidad.
Facilidad de
• Simplicidad.
prueba
• Auto descripción.
• Instrumentación: Atributos del software que posibilitan la observación
del comportamiento del software durante su ejecución para facilitar las
mediciones del uso o la identificación de errores.
Flexibilidad
• Capacidad de expansión: Atributos del software que posibilitan la

expansión del software en cuanto a capacidades funcionales y datos.
• Generalidad: Atributos del software que proporcionan
proporcionan amplitud a las
funciones implementadas.
• Modularidad.
Generalidad.
Reusabilidad
•
• Modularidad.
• Independencia
ndependencia entre sistema y software: Atributos del software que
determinan su dependencia del entorno operativo.
TRANSICION DEL PRODUCTO
• Independencia del hardware: Atributos del software que determinan su

dependencia del hardware.
• Modularidad.
Interoperabilidad
• Compatibilidad de comunicaciones: Atributos del software que posibilitan

el uso de protocolos de comunicación e interfaces estándar.
• Compatibilidad de datos: Atributos del software que posibilitan el uso
representaciones de datos estándar.
• Estandarización en los datos: El uso de estructuras de datos y de tipos
estándar a lo largo de todo el programa.
Portabilidad
• Modularidad.
• Independencia
ndependencia entre sistema y software.
• Independencia del hardware.

CALIDAD DE SOFTWARE
Cómo emplear el modelo de Mc-Call.

Mc
Antes de comenzar a utilizar el modelo de McCall hay que seguir las siguientes pautas:
1. Se aceptan los factores, criterios y métricas que propone el modelo.

2. Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas.
3. Se selecciona un subconjunto de factores de calidad sobre los que aplicar los requisitos de
calidad establecidos para el proyecto.
Al comienzo
ienzo del proyecto habrá que especificar los requisitos de calidad del producto
software, para lo cual se seleccionarán los aspectos inherentes a la calidad deseada del
producto, teniendo que considerarse para ello:
♦ Las características particulares del propio

propio producto que se está diseñando: por ejemplo, su
ciclo de vida que si se espera que sea largo implicará un mayor énfasis en la facilidad de
mantenimiento y la flexibilidad, o bien si el sistema en desarrollo está destinado a un
entorno donde el hardware
hardware evoluciona rápidamente implicará como requisito su
portabilidad.
precio, que puede evaluarse a través del coste de cada factor de calidad
♦ La relación calidad-precio,
frente al beneficio que proporciona. La siguiente tabla muestra la relación calidad-precio
calidad
para cada factor considerado:
Factor Beneficio/Coste
Corrección alto
Fiabilidad alto
Eficiencia bajo
Integridad bajo
Facilidad de uso medio
Facilidad de mantenimiento alto
Facilidad de prueba alto
Flexibilidad medio
Portabilidad medio
Reusabilidad medio
Interoperabilidad bajo
♦ La determinación de las etapas del ciclo de vida donde es necesario evaluar cada factor de
calidad para conocer en cuales se dejan sentir más los efectos de una calidad pobre con
respecto a cada uno de los factores.
♦ Las propias interrelaciones entre los factores debido a que algunos factores pueden entrar
en conflicto entre sí: por ejemplo, la eficiencia plantea conflictos prácticamente con todos
los demás factores de calidad. La interacción entre los diversos factores a evaluar queda
reflejada en la tabla I que indica la dependencia entre los factores de McCall.
También habrá que establecer valores deseables para los criterios, para lo cual se emplearán
datos históricos, el promedio en la industria, y con ellos se concretarán
concretarán los valores finales y
otros intermedios o predictivos en cada período de medición durante el desarrollo, así como
unos valores mínimos aceptables.
La explicación para cualquier selección o decisión deberá ser adecuadamente documentada.

En la fase de desarrollo será necesario implementar las métricas elegidas, analizar sus
resultados y tomar medidas correctivas cuando los valores obtenidos estén por debajo de los
mínimos aceptables.
Una vez finalizado el proyecto será necesario contrastar las medidas predictivas utilizadas y

CALIDAD DE SOFTWARE
comprobar si, en efecto, se pueden tomar como indicadores de los valores finales.
Descripción de los factores Mc-Call

Mc
1. Corrección: Hasta qué punto un programa cumple sus especificaciones y satisface los
objetivos del usuario. Por ejemplo, si un programa debe ser capaz de sumar dos números
y en lugar de sumar los multiplica, es un programa incorrecto. Es quizás el factor más
importante,e, aunque puede no servir de nada sin los demás factores.
2. Fiabilidad: Hasta qué punto se puede confiar en el funcionamiento sin errores del
programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25% de
los casos el resultado que da no es correcto, es poco fiable.
3. Eficiencia: Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un
programa para desempeñar su función. Un programa que suma dos números y necesita 2
MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta, es poco
eficiente.
4. Integridad: Hasta qué punto se controlan los accesos ilegales a programas o datos. Un
programa que permite el acceso de personas no autorizadas a ciertos datos es poco
íntegro.
5. Facilidad de uso: El coste y esfuerzo de aprender
aprender a manejar un producto, preparar la
entrada de datos e interpretar la salida del mismo.
6. Facilidad de mantenimiento: El coste de localizar y corregir defectos en un programa
que aparecen durante su funcionamiento.
7. Facilidad de prueba: El coste de probarr un programa para comprobar que satisface sus
requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de
un sistema para poder probar que funciona bien, es un programa difícil de probar.
8. Flexibilidad: El coste de modificación del producto cuando cambian sus especificaciones.
9. Portabilidad (o Transportabilidad): El coste de transportar o migrar un producto de una
configuración hardware o entorno operativo a otro.
10. Facilidad de Reutilización: Hasta qué punto se puede transferir un módulo o programa
del presente sistema a otra aplicación, y con qué esfuerzo.
11. Interoperabilidad: El coste y esfuerzo necesario para hacer que el software pueda
operar conjuntamente con otros sistemas o aplicaciones software externos.
Cada uno de estos factores

tores se descompone, a su vez, en criterios. En el modelo de McCall se
definen un total de 23 criterios, con el siguiente significado:
1. Facilidad de operación: Atributos del software que determinan la facilidad de operación

del software.
2. Facilidad de comunicación:
comun Atributos del software que proporcionan al usuario
entradas y salidas fácilmente asimilables.
3. Facilidad de aprendizaje: Atributos del software que facilitan la familiarización inicial
del usuario con el software y la transición desde el modo actual de operación.
4. Control de accesos: Atributos del software que proporcionan control de acceso al
software y los datos que maneja.
maneja
5. Facilidad de auditoría: Atributos del software que facilitan el registro y la auditoría de
los accesos al software.
6. Eficiencia en ejecución: Atributos del software que minimizan el tiempo de
procesamiento.
7. Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de
almacenamiento necesario.
8. Precisión: Atributos del software que proporcionan el grado de precisión requerido en los
cálculos y los resultados.
9. Consistencia: Atributos del software que proporcionan uniformidad
uniformidad en las técnicas y
notaciones de diseño e implementación utilizadas.
10. Tolerancia a fallos: Atributos del software que posibilitan la continuidad del
funcionamiento bajo condiciones no usuales.

CALIDAD DE SOFTWARE
11. Modularidad: Atributos del software que proporcionan una estructura

est de módulos
altamente independientes.
12. Simplicidad: Atributos del software que posibilitan la implementación de funciones de la
forma más comprensible posible.
13. Completitud: Atributos del software que proporcionan la implementación completa de
todas las
as funciones requeridas.
14. Trazabilidad (Rastreabilidad): Atributos del software que proporcionan una traza desde
los requisitos a la implementación con respecto a un entorno operativo concreto.
15. Auto descripción: Atributos del software que proporcionan explicaciones
expli sobre la
implementación de las funciones.
16. Capacidad de expansión: Atributos del software que posibilitan la expansión del
software en cuanto a capacidades funcionales y datos.
17. Generalidad: Atributos del software que proporcionan amplitud a las funciones fun
implementadas.
18. Instrumentación: Atributos del software que posibilitan la observación del
comportamiento del software durante su ejecución (para facilitar las mediciones del uso o
la identificación de errores).
19. Independencia entre sistema y software:
software Atributos del software que determinan su
independencia del entorno operativo.
20. Independencia del hardware: Atributos del software que determinan su independencia
del hardware.
21. Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso us de
protocolos de comunicación e interfaces estándar.
22. Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones
de datos estándar.
23. Concisión: Atributos del software que posibilitan la implementación de una función con la
menorr cantidad de código posible.

CALIDAD DE SOFTWARE
MÉTRICAS DE CALIDAD DE SOFTWARE
ESTÁNDAR ISO 9126
Introducción
El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos de de calidad
para el software.
ware. El estándar identifica seis atributos clave de calidad:
• Funcionalidad.. El grado en que el software satisface las necesidades indicadas por los
siguientes sub-atributos:
atributos: idoneidad, corrección, interoperavilidad, conformidad y
seguridad.
• Confiabilidad.. Cantidad de tiempo que el software está disponible para su uso. Está
referido por los siguientes sub-atributos:
sub atributos: madurez, tolerancia a fallos y facilidad de
recuperación.
• Usabilidad.. Grado en que el software es fácil de usar. Viene reflejado por los siguientes
sub-atributos:
butos: facilidad de comprensión, facilidad de aprendizaje y operatividad.
• Eficiencia.. Grado en que el software hace óptimo el uso de los recursos del sistema. Está
indicado por los siguientes sub-atributos:
sub atributos: tiempo de uso y recursos utilizados.
• Facilidad de mantenimiento.
mantenimiento. La facilidad con que una modificación puede ser
realizada. Está indicada por los siguientes sub-atributos:
sub atributos: facilidad de análisis, facilidad de
cambio, estabilidad y facilidad de prueba.
• Portabilidad. La facilidad con que el software puede ser ser llevado de un entorno a otro.
Está referido por los siguientes sub-atributos:
sub atributos: facilidad de instalación, facilidad de ajuste,
facilidad de adaptación al cambio.
Los factores ISO 9126 no necesariamente son utilizados para medidas directas. En cualquier casoc
facilitan una valiosa base para medidas indirectas y una excelente lista para determinar la calidad
de un sistema.
La transición a una visión cuantitativa
En las separatas precedentes se estudiaron un conjunto de factores cualitativos para la

«medición»
ón» de la calidad del software. Intentamos desarrollar medidas exactas de la calidad
del software frustradas a veces por la naturaleza subjetiva de la actividad. Cavano y McCall
estudian esta situación:
La determinación de la calidad es un factor clave en los acontecimientos diarios: concursos de

cata de vinos, acontecimientos deportivos (por ejemplo, la gimnasia), concursos de talento,
etc. En estas situaciones, la calidad se juzga de la manera más fundamental y directa:
comparación de objetos unos al ladoo de los otros bajo condiciones idénticas y con conceptos
predeterminados. El vino puede ser juzgado de acuerdo con su claridad, color, bouquet,
sabor, etc. Sin embargo, este tipo de juicio es muy subjetivo; para que tenga algo de valor,
debe hacerse por un
n experto.
La subjetividad y la especialización también influyen en la determinación de la calidad del

software. Para resolver este problema, se necesita una definición de calidad del software más
exacta, así como una manera de obtener medidas cuantitativas
cuantitativas de la calidad del software para

CALIDAD DE SOFTWARE
hacer un análisis objetivo....

vo.... Como no existe el conocimiento absoluto, no deberíamos esperar
poder medir la calidad del software exactamente, ya que cada medición es parcialmente
imperfecta.
En las siguientes secciones

iones examinamos un conjunto
conjunto de métricas del software que pueden
aplicarse a la valoración cuantitativa de la calidad del software. En todos los casos, las
métricas representan medidas indirectas;
indirectas; es decir, realmente nunca medimos la calidad sino
alguna manifestación de la calidad. El factor que lo complica es la relación exacta entre la
variable que se mide y la calidad del software.
Métricas de calidad de software
1. Corrección: Hasta qué punto un programa cumple sus especificaciones y satisface los
objetivos del usuario. Por ejemplo, si un programa debe ser capaz de sumar dos números
y en lugar de sumar los multiplica, es un programa incorrecto. Es quizás el factor más
importante,
e, aunque puede no servir de nada sin los demás factores.
Número de requerimientos implementados

Corrección = -----------------------------------------------------------------------
Número de requerimientos determinados en el análisis
CALIDAD DE SOFTWARE
2. Fiabilidad: Hasta qué punto se puede confiar en el funcionamiento sin errores del
programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25% de
los casos el resultado que da no es correcto, es poco fiable.
Fiabilidad = 1 - (número de errores / número de

e intentos)
3. Eficiencia: Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un

programa para desempeñar su función. Un programa que suma dos números y necesita
2MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta, es poco
eficiente. Para ell cálculo de la eficiencia, se debe medir el valor por cada función o
módulo según los siguientes parámetros: (ISO 9126)
• Uso de Procesador (en porcentaje) UP

La cantidad de procesador que emplea el módulo durante su ejecución
• Uso de Memoria (en megabytes) UM
La cantidad de memoria que emplea el módulo durante su ejecución
• Tiempo (en segundos) T
La cantidad de segundos que emplea el módulo para efectuar cálculos
La eficiencia está dada por las fórmulas:
UP--Promedio = UP-Disponible / Número de

e Módulos
UM--Promedio = UM-Disponible
Disponible / Número de Módulos
T-Promedio
Promedio = T-Disponible
T / Número de Módulos
Se calculará las eficiencias parciales por cada módulo:
Eficiencia-UP(i) = UP(i) / UP-Promedio

Eficiencia
Eficiencia
Eficiencia-UM(i) = UM(i) / UM-Promedio
Eficiencia
Eficiencia-T(i) = T(i) / T-Promedio
Se calculará la eficiencia final:
n
Σ [Eficiencia-UP(i)+Eficencia-UM(i)+Eficencia-T(i)]
[Eficiencia /3
i=1
Eficiencia = 1 -
Número de módulos (n)
4. Integridad: Hasta qué punto se controlan los accesos ilegales a programas o datos. Un
programa que permite el acceso de personas no autorizadas a ciertos datos es poco
íntegro.
Integridad = 1-(número
1 (número de accesos ilegales/número total de accesos)
5. Mantenimiento: El coste de localizar y corregir defectos en un programa que aparecen

durante su funcionamiento.
Mantenimiento = 1 - 0.1 (número medio de días-hombre

hombre por corrección)
6. Índice de madurez del software:
IMS = [ MT - ( FA + FC + FD ) ] / MT

CALIDAD DE SOFTWARE
Donde:
MT: Número de módulos de la versión actual
FC: Número de módulos en la versión actual que han cambiado
FA: Número de módulos en la versión actual que se han añadido
FD: Número de módulos de la versión anterior que se ha borrado en la actual
A medida que el IMS se aproxima
aproxima a 1.0 el producto se empieza a estabilizar. EL IMS
puede emplearse también
también como métrica para la planificación de las actividades
activi de
mantenimiento del software. El tiempo medio para producir una versión de un
producto software puede
pue correlacionarse con el IMS desarrollándose modelos
mode
empíricos para el mantenimiento.
7. Flexibilidad: El coste de modificación del producto cuando cambian sus especificaciones.
exibilidad = 1 - 0.05 (número medio de días-hombre

Flexibilidad hombre por cambio)
8. Capacidad de Pruebas: El coste e de probar un programa para comprobar que satisface

sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa
de un sistema para poder probar que funciona bien, es un programa difícil de probar.
CP = 1-(número
(número de funciones probadas/número total de funciones)
9. Portabilidad (o Transportabilidad):
Transportabilidad): El coste de transportar o migrar un producto de
una configuración hardware o entorno operativo a otro.
Portabilidad = 1-(esfuerzo
1 (esfuerzo para portar/esfuerzo para implementar)
10. Reusabilidad: Hasta qué punto se puede transferir un módulo o programa del presente
sistema a otra aplicación, y con qué esfuerzo.
Reusabilidad = Σ portabilidad por módulo

módulo / número total de módulos
11. Interoperabilidad: El coste y esfuerzo necesario para hacer que el software

s pueda
operar conjuntamente con otros sistemas o aplicaciones software externos.
Interoperabilidad = módulos integrados / módulos del software
12. Usabilidad: El coste y esfuerzo de aprender a manejar un producto, preparar la entrada

de datos e interpretar
pretar la salida del mismo.
Tiempo medio de aprendizaje por módulo

Usabilidad = ---------------------------------------------------------------
Tiempo de aprendizaje total / Número de módulos

CALIDAD DE SOFTWARE
EJECUCIÓN DEL CONTROL DE CALIDAD DE SOFTWARE
Introducción
El objetivo de las actividades de Control de Calidad es comprobar si un producto posee o no

posee una determinada característica de calidad en el grado requerido. Cuando un producto
no posee una determinada característica de calidad se dice que tiene un DEFECTO. Por lo
tanto, se puede decir también que el objetivo del Control de Calidad es identificar defectos en
el producto y corregirlos.
Se pueden clasificar las actividades de control de calidad en dos categorías:
cate controles
estáticos y controles dinámicos. Los primeros analizan el objeto sin necesidad de ejecutarlo
mientras que los segundos requieren la ejecución del objeto que está siendo probado.

CALIDAD DE SOFTWARE
La barrera entre controles estáticos y dinámicos no es totalmente estricta. Cualquier forma de

control dinámico requiere un cierto grado de análisis estático. Además hay algunas técnicas,
como la verificación formal y la ejecución simbólica, consideradas como estáticas, que
"ejecutan" el código, aunque en un entorno no real.
CONTROLES ESTÁTICOS
Controles Estáticos Manuales
Controles estáticos manuales informales
Estas actividades las realizan los propios autores de los objetos a comprobar, o personas de
su misma categoría y ocupación.
Comprobación de escritorio (desk checking):
Consiste en examinar a mano e individualmente el objeto que se acaba de desarrollar. Es el

método más tradicional para analizar un programa. Se debe aplicar a los requisitos,
especificaciones de diseño y código según se van desarrollando.
desarrollando. Debe ser cuidadoso y
concienzudo para que sea efectivo. Es más efectivo si se hace intercambiando el objeto a
examinar con otro compañero.
Revisión por pares o iguales (peer review):
Consiste en la revisión del código de un programador por otros

otros programadores (sus pares).
Se puede poner en práctica creando un panel que se encarga de revisar periódicamente
muestras de código.
Controles estáticos manuales disciplinados
Las revisiones y auditorías son la evolución natural de la Comprobación de Escritorio, pero a

diferencia de aquélla pasan a ser técnicas de grupo. Su misión principal es conseguir que la
responsabilidad del control de calidad no recaiga sólo sobre el propio desarrollador.
Auditorias
Una auditoría consiste en realizar una investigación para determinar:
- El grado de cumplimiento y la adecuación de los procedimientos, instrucciones,

especificaciones, códigos, estándares u otros requisitos de tipo contractual establecidos
y aplicables.
- La efectividad y adecuación de la implementación
imple realizada.
Se pueden considerar tres tipos de auditorías:
1.- Auditoría del producto: El objetivo es cuantificar el grado de conformidad del

producto con las características requeridas. Las auditorías del producto software más
comunes son la auditoría
a Funcional y la auditoría Física.
2.- Auditoría del proceso: El objetivo es evaluar el proceso de desarrollo o de

gestión, y evaluar su completitud y efectividad, determinando dónde se puede
mejorar. En el desarrollo de software se suelen realizar dos tipos de auditorías del
proceso:
- Auditorías de proyecto: cuyo objetivo es evaluar la productividad y

CALIDAD DE SOFTWARE
eficacia del equipo que trabaja en un proyecto así como la efectividad de los
métodos y herramientas utilizados.
- Auditorías de gestión de proyecto: cuyo objetivo es evaluar la

efectividad de las prácticas de gestión realizadas y la organización del
proyecto.
3.- Auditoría del sistema de calidad: El objetivo es evaluar la completitud y

efectividad del propio sistema de calidad establecido.
El procedimiento habitual para realizar una auditoría consta de los siguientes pasos:
1. Planificación: Consiste en definir los objetivos de la auditoría y su alcance. En esta etapa se

elabora un Plan de Auditoría, que debería dar respuesta a cuestiones cuestione del tipo de las
siguientes:
- ¿Por qué se realiza la auditoría? Puede ser una auditoría de rutina o puede realizarse
para resolver problemas concretos.
- ¿Para qué se realiza? para mejorar, para conseguir una certificación,... ¿Cuál
es el producto que va a ser auditado?
- ¿Qué resultados se esperan de la auditoría? En principio, una auditoría debería
identificar situaciones problemáticas, tales como desviaciones del estado actual con
respecto al estado deseado, y sugerir posibles soluciones o mejoras.
¿Cómo y dónde se van a utilizar los resultados de la auditoría?
- ¿Quiénes son los responsables de llevarla a cabo?
¿De qué forma se va a llevar a cabo? Incluyendo una especificación de los datos que
se van a recoger y de qué forma se van a recoger.
¿Cuándo se va a realizar?
2. Llevar a cabo la investigación. Por lo general la auditoría se inicia con una reunión de
apertura de la investigación, y se lleva a cabo mediante entrevistas y revisiones en las que se
recopilan datos.
3. Analizar los datos recogidos.

ecogidos. Por lo general el equipo de auditores debe hacer frente a
cantidades ingentes de datos, de entre los cuales resulta complicado seleccionar los datos
relevantes, por lo que se suelen utilizar técnicas de análisis estadístico. A continuación se
realiza
liza una evaluación en paralelo de los resultados por un grupo de evaluadores, se
comparan las conclusiones obtenidas y se estudian las causas de las desviaciones
significativas.
4. Sugerir soluciones a los problemas encontrados y posibles mejoras.
5. Elaborar
aborar y presentar un informe de resultados.

CALIDAD DE SOFTWARE
Revisiones
Se puede definir una revisión como una reunión formal en la que se presenta el estado actual
de los resultados de un proyecto a un usuario, cliente u otro tipo de persona interesada, y se
realiza un análisis estructurado de los mismos.
Uno de los objetivos fundamentales de las revisiones técnicas es ofrecer a los gestores
información fiable acerca de los aspectos técnicos del proceso de desarrollo de software, de la
misma forma que les llega información
información fiable acerca de los costes y la programación del
trabajo, para que con esta información puedan tomar decisiones adecuadas para dirigir con
éxito el proyecto.
Con las revisiones se consigue que el peso de la evaluación técnica no recaiga sobre las
mismas
ismas personas involucradas en la producción del software, que por la posición que ocupan
no pueden ser totalmente objetivas, sino en otras personas técnicamente competentes y
objetivas.
Las revisiones son, hoy en día, el único método de control de calidad eficaz en las fases
iniciales del desarrollo a la hora de identificar desviaciones con respecto a las especificaciones
de calidad.
Las revisiones redundan en una mejora directa de la calidad del objeto que se examina y
provocan, indirectamente, una mejora de la calidad del proceso de desarrollo, al facilitar la
comunicación entre los miembros del equipo de desarrollo. Al mismo tiempo facilitan el control
del coste y el tiempo.
Las diferencias más importantes entre las revisiones y las auditorías son las siguientes:
si
- Las revisiones se llevan a cabo desde las primeras fases del desarrollo, mientras que las
auditorías se llevan a cabo en las fases finales.
- El objetivo de las revisiones es detectar defectos, mientras que el objetivo de las

auditorías es certificar conformidad e identificar desviaciones.
Tipos de revisiones
Hay dos tipos fundamentales de revisiones: las inspecciones y los walkthrough. La diferencia
entre ellos está en la forma en que se desarrolla la reunión de revisión.
- Inspecciones: En las que los participantes van leyendo el documento, paso a paso,
guiados por el autor del mismo, y comprobando en cada paso el cumplimiento de los
criterios de una lista de comprobación.
- Walkthrough (visita guiada): En las que se demuestra la funcionalidad

funcionalidad del objeto revisado
mediante la simulación de su funcionamiento con casos de prueba y ejemplos. Se
introducen al objeto los casos de prueba y se van registrando los resultados intermedios.
Aunque estos son los tipos ideales, en la vida real hay

hay otras muchas variantes intermedias,
desde las revisiones sin disciplina alguna hasta cualquier tipo de mezcla entre inspecciones y
walkthrough.
Otras diferencias esenciales entre inspecciones y walkthrough son las siguientes:

CALIDAD DE SOFTWARE
- Los walkthrough están planteados

planteados como una medida de ayuda al desarrollador,
mientras que las inspecciones están planteadas como una medida de ayuda al gestor.
En los walkthrough el objetivo fundamental es incrementar el entendimiento,
comprender mejor el objeto, mientras que en las
las inspecciones el objetivo es detectar
defectos.
- En las inspecciones el proceso está guiado por la lista de comprobación, y en los

walkthrough está guiado por la estructura del producto revisado.
- Las inspecciones se planifican y procesan de una manera mucho más formal que los
walkthrough. Se usan para asegurar la satisfacción de los criterios de salida
establecidos entre diferentes etapas del desarrollo (revisiones de fase).
La siguiente tabla resume

esume algunas diferencias adicionales entre ellas:
Propiedades Inspección Walkthrough
1. Requiere entrenamiento formal del moderador SI NO

2. Hay unos roles definidos para los participantes SI NO
3. Quién guía la revisión El moderador El propietario del

producto revisado
4. Se usan listas de comprobación SI NO
5. Se usan distribuciones por tipo de los errores a buscar SI NO
6. Hay un seguimiento para controlar que la corrección es SI NO

correcta
7. Se puede mejorar la eficiencia de la revisión analizando los SI NO
resultados
Fases en una Inspección:
1. Planificación: La preparación comienza con la selección de los participantes. Debe

designarse un coordinador o moderador; un secretario; un presentador, de entre los
productores del objeto que se revisa; y otros revisores, que pueden ser desarrolladores,
representantes de los usuarios, revisores externos; y posiblemente otros.
El coordinador es responsable de la planificación de la inspección, de moderar la reunión
(mantener el orden, mantener el foco de la revisión, asegurar que se cubren todos los
aspectos necesarios), de preparar el informe final y de realizar el seguimiento y evaluación de
las acciones pendientes.
El secretario es responsable de anotar los elementos de interés (defectos y anomalías
descubiertas, acciones pendientes) y ayudar al coordinador en la preparación
prepa del informe
final.
En la planificación es también necesario determinar:
- Los objetivos de la inspección
- Los criterios de finalización de la inspección
- El lugar y la fecha para la inspección
- La disponibilidad de todos los participantes
- La agenda
enda de la reunión
2. Orientación inicial: Es recomendable realizar una reunión de orientación, previa a la

inspección propiamente dicha, cuando se trata de examinar por primera vez un objeto, para
dar a los participantes en la revisión una idea del objeto
objeto que van a revisar.

CALIDAD DE SOFTWARE
3. Preparación individual: Con suficiente tiempo antes de la realización de la inspección, se

debe hacer llegar a cada revisor una copia de la documentación asociada al objeto que se va
a revisar, junto con una lista de comprobaciones o "checkiist" enumerando los posibles
defectos que se deben intentar localizar. Una lista de comprobaciones contiene una serie de
preguntas, y se supone que al intentar dar respuesta a estas preguntas saldrán a la luz los
problemas que puedan existir. Cada
Cada revisor debe completar la lista y anotar cualquier tipo de
pregunta o defecto detectado.
4. Reunión de inspección: Durante la reunión, el presentador o autor del objeto revisado

va guiando al resto a través del mismo para comprobar cada uno de los puntos
punto de la lista de
comprobación. Hay varias formas de guiar la reunión:
- Punto por punto de la lista de comprobación, revisando todo el producto para cada
uno de ellos.
- Componente a componente del producto, revisando todos los puntos de la lista de
comprobación para cada componente.
- Por grupos de puntos dentro de la lista de comprobación, revisando todo el producto
para cada grupo.
- Cualquier otra solución intermedia
Los defectos que se detecten durante este proceso se añaden a una lista de acciones
pendientes.
Hay que tener en cuenta que el objetivo de una inspección es descubrir defectos, no
corregirlos. Por otro lado, los revisores deben restringirse a los hechos y ser constructivos. Es
misión del moderador asegurarse de que esto se cumple.
cumpl
Al final de la reunión de inspección, los participantes valoran los resultados de la inspección y

se completa un informe. Al finalizar la reunión se pueden producir las siguientes situaciones:
- Se cierra la inspección sin que se hayan encontrado defectos.

defe
- Se cerrará la inspección después de que los defectos encontrados se hayan
eliminado en la fase de seguimiento.
- No se cierra la inspección porque se encontraron defectos importantes, y será
necesario realizar una nueva inspección.
5. Seguimiento: Durante esta fase, el autor del objeto revisado se encarga de corregir los
defectos encontrados y generar un informe en el que se especifican las acciones correctivas
realizadas para eliminar los distintos defectos.
6. Evaluación: Es la última fase y en ella se trata de determinar si se han corregido todos los
defectos y si han surgido nuevos problemas durante el proceso de corrección. El moderador
se encarga de realizar la evaluación y enviar un informe a la dirección una vez finalizada.
Documentos generados en una inspección
Algunos de los informes o documentos que pueden generarse como resultado de una
inspección son los siguientes:
- Informe resumen de la inspección: Conclusiones breves de la inspección

(una página o dos) para la dirección:
- Qué se ha revisado
- Quién lo ha revisado
- Cuál fue la conclusión

CALIDAD DE SOFTWARE
- Lista de acciones pendientes: Es un informe para los autores del producto

revisado explicando qué es lo que está mal y, si puede ser, cómo corregirlo.
Necesita ser claro, pero no muy elaborado. Es un documento técnico y
transitorio. No debe llegar a la dirección, para no aburrirlos con tantos
datos y para que no puedan usar esta información en perjuicio del proceso
de inspección.
- Informe de asuntos relacionados: Para registrar problemas
roblemas que salen a la
luz durante la inspección pero no están relacionados directamente con el
objeto revisado, para que sean notificados a la persona responsable.
- Informe del proceso de inspección: Cuando algo ha salido mal en el proceso
de inspección
spección en sí mismo.
- Informe final: Para informar a la dirección del cierre de la inspección.
Fases en un Walkthrough:

CALIDAD DE SOFTWARE
El proceso para realizar un walkthrough es mucho más sencillo y consta de tan sólo tres
fases:
1. Planificación: Similar a la planificación de una inspección, con la diferencia

de que no es necesario asignar roles específicos a los participantes, a excepción
del presentador, que es quien organiza el walkthrough y guía la reunión.
2. Preparación individual: Cada revisor sor examina el objeto revisado, aunque en

este caso no se les entregará una lista de comprobación.
3. Reunión de walkthrough
La siguiente tabla resume las fases de inspecciones y walkthrough e indica los objetivos que
se persiguen en cada una de ellas:
Inspección Walkthrough
Etapas Objetivo Etapas Objetivo
1. Orientación Educación (grupo) - -
2. Preparación Educación (individual) 1. Preparación Educación (individual)

individual individual
3. Reunión Encontrar errores (grupo) 3. Reunión Educación (grupo)

Discusión de alternativas
de diseño Encontrar
errores
4. Seguimiento Arreglar problemas - -
5. Evaluación Asegurar que todos los - -

problemas se han resuelto
correctamente
Formalidad en las revisiones
Se puede diferenciar también entre las revisiones formales e informales. Se dice que una
revisión es formal cuando:
- Es un evento público
- Se informa por escrito de los resultados
- Todos los participantes son responsables de la calidad de la revisión.
La ventajaja de realizar revisiones formales es que los informes que se generan sirven
como hitos para el proyecto, y el hecho de ser algo público promueve una mejor
preparación por parte de los participantes. Por contra, la formalidad hace que este tipo de
reunioness sean un tanto impersonales.
Para evitar que los participantes se sientan intimidados por el ambiente impersonal y
expresen libremente sus opiniones se pueden utilizar técnicas como el Round-robin,
Round que
consiste en ir pasando el tumo de uno a otro por todos los participantes en la revisión.
Revisiones técnicas y de gestión
Por otro lado, según el objeto que se revise, se suele diferenciar entre las revisiones con
orientación técnica y las revisiones
revisiones orientadas a la gestión (también conocidas como
revisiones de proyecto).

CALIDAD DE SOFTWARE
Las revisiones técnicas más comunes son:
- Revisión de la especificación de requisitos

- Revisión del diseño
- Revisión del código
- Revisión de las pruebas
- Revisión del manual de
d usuario
Los principales objetivos que se buscan con las revisiones de proyecto, por otro lado, son los
siguientes:
- Control de la progresión del proyecto
- Evaluación de los riesgos asociados al proyecto, con relación al coste, escala de
tiempos, recursos utilizados y calidad del producto.
- Evaluación general del producto.
Para que esto sea posible es
necesario:
- Que exista un plan de desarrollo bien estructurado, con hitos bien definidos, que
permita evaluar la progresión del proyecto.
- Que los resultados del proyecto se encuentren bien documentados y hayan sido
ya examinados en una revisión técnica.
A continuación vamos a examinar en más detalle las revisiones técnicas más comunes.
Revisión de la especificación de requisitos
Este tipo de revisión es muy

muy útil para facilitar el descubrimiento de los errores introducidos en
la especificación de requisitos en fases tempranas del desarrollo.
El tipo de errores que se pueden encontrar en este objeto son:
- Requisitos poco claros, contradictorios, erróneos o imposibles
imposibles de probar
- Requisitos incompletos o especificación incompleta (faltan requisitos).
- Requisitos irrelevantes para el problema que se trata de resolver.
Algunas de las preguntas que podrían encontrarse en una lista de comprobaciones para la
especificación
cificación de requisitos son las siguientes:
- ¿Se han especificado todos los recursos hardware necesarios?

- ¿Se han especificado las interfaces externas necesarias?
- ¿Existen contradicciones en la especificación de los requisitos?
- ¿Se han definido los criterios de aceptación para cada una de las funciones
especificadas?
- ¿Resulta comprensible la especificación realizada?
Revisión del diseño
Se suele diferenciar entre la revisión del diseño preliminar o de alto nivel y la revisión del
diseño detallado.
etallado. El objetivo de estas revisiones es determinar y evaluar el estado en el que
se encuentra el proceso de diseño, así como descubrir errores o contradicciones (entre la
especificación de requisitos y el diseño o en las interfaces entre módulos)
Algunas
nas de las preguntas que podrían encontrarse en una lista de comprobaciones para el
diseño son las siguientes:
- ¿Hay uniformidad en el diseño?

- ¿Se han definido correctamente las interfaces entre módulos?
- ¿Se han definido correctamente las interfaces extemas?
- ¿Cubre el diseño todas las funciones incluidas en la especificación de requisitos?
- ¿Cumple el diseño todos los requisitos no funcionales?

CALIDAD DE SOFTWARE
- ¿Resulta ambigua la documentación del diseño?

- ¿Se ha aplicado la notación de diseño correctamente?
- ¿Es el diseño lo suficientemente detallado como para que sea posible impí ementarlo
en el lenguaje de programación elegido?
Revisión del código
Las revisiones del código suelen tomar la forma de revisión por pares o inspección, y uno de
sus objetivos es determinar que el código se corresponde con el diseño detallado realizado.
Algunos de los aspectos que se examinan en una revisión de código son los siguientes:
- interfaces
- estructura del programa
- utilización de variables
- fórmulas
- entradas y salidas
- comentarios
- adherencia a los estándares de codificación
Las revisiones de código se basan en la lectura del mismo, lo que exige de los programadores
un esfuerzo para hacerlo legible.
Los estudios realizados demuestran que, mediante las inspecciones
inspecciones de código, más de la
mitad de los errores de programación se pueden detectar antes de pasar a la prueba modular
y que los programas que han pasado por una inspección de código contienen
considerablemente menos errores.
Revisiones de las pruebas
Se pueden efectuar dos tipos de revisiones de las pruebas:
- Revisión del diseño de la prueba

- Inspección de la prueba
El objetivo de la revisión del diseño de la prueba es comprobar que el diseño realizado para la
prueba está de acuerdo con los objetivos que se persiguen. Se deben comprobar aspectos
como:
- ¿Se han tenido en cuenta todos los objetivos a la hora de diseñar los casos de
prueba?
- ¿Se han elegido los casos de prueba más adecuados para comprobar la consecución
de dichos objetivos?
Los objetivos
vos de las inspecciones de las pruebas, por su parte, son:
- Comprobar que la prueba se ha ejecutado correctamente, de acuerdo con el

procedimiento de prueba especificado.
- Análisis de los resultados obtenidos con cada prueba.
Controles Estáticos Automáticos
Dentro de esta categoría tenemos el análisis estático automático y la verificación formal de

programas.
La mayor parte del análisis estático automático del código lo realizan los compiladores, que
pueden detectar desde expresiones sintácticamente
sintácticamente incorrectas hasta incompatibilidades
de tipo y otros errores de tipo semántico.
Verificación formal

CALIDAD DE SOFTWARE
Consiste en demostrar matemáticamente la corrección de un programa con respecto a sus

especificaciones.
Para ello, se considera el programa como

como un objeto formal, es decir, como una cadena de un
lenguaje formal, con una sintaxis y una semántica formal. Es también necesario que la
especificación se haya escrito en algún lenguaje formal. Por eso no siempre es posible realizar
este tipo de verificación.
Por lo general, esta técnica sólo se utiliza para sistemas críticos, debido al coste que conlleva.
Los métodos de verificación formal de programas más conocidos son los basados en la lógica
de Hoare [Hoare, 1969], los basados en la aproximación de Dijkstra [Dijkstra, 1989] y la
aproximación funcional de Milis [Milis, 1987].
CONTROLES DINÁMICOS
Introducción
Se llama controles dinámicos a aquellos que requieren la ejecución del objeto que se está
probando o de un modelo del mismo.
Hasta la fecha no se ha desarrollado ninguna teoría universalmente aceptada acerca de la
prueba de software. Lo único que hay es un conjunto de aproximaciones metodológicas que
facilitan y hacen más eficiente el proceso de prueba.
Se llama PRUEBA del Software al proceso en el que se ejecuta un sistema con el objetivo de
detectar fallos.
Se llama DEPURACIÓN al proceso en el que se localiza el defecto que es la causa de un fallo,

se determina la forma de corregirlo, se evalúa el efecto de la corrección y se lleva a cabo la
l
corrección. Por lo general, después del proceso de depuración será necesario repetir el
proceso de prueba, para garantizar que el defecto quedó efectivamente corregido y que no se
introdujeron nuevos defectos.
El coste de detección de los defectos suele ser mucho mayor que el coste de corrección de los
mismos, y este es un punto en contra de las pruebas como técnica de control de calidad, ya
que siempre es necesario un paso de diagnóstico hasta que se localiza la causa de los fallos.
En otras actividades de control de calidad, por el contrario, como pueden ser las revisiones, se
localizan directamente los defectos, no sus síntomas, por lo que nos ahorramos el proceso de
diagnóstico.
En un proyecto grande la prueba se puede llevar hasta el 50 o 60% del esfuerzo

es dedicado al
proyecto. Por eso es muy importante seleccionar bien las pruebas que se van a realizar,
teniendo en cuenta que sólo las pruebas que revelan defectos son las que realmente merecen
la pena.
El objetivo del proceso de prueba no es, como pudiera

pudiera parecer, demostrar que el software
está libre de defectos, sino precisamente descubrir defectos. Por ello, se deben seleccionar
especialmente aquellos casos de prueba que incidan en las secciones del programa más
complejas, en los valores límite de las
las variables, en la tolerancia a fallos del diseño.
Aunque la prueba es una parte importante del Control de Calidad, es importante darse cuenta
de que no es la única.
A continuación veremos cuáles son las actividades que es necesario realizar para probar un
sistema software, y cuáles son los principales métodos de prueba que se pueden utilizar.

CALIDAD DE SOFTWARE
Tipos de pruebas
El proceso de prueba conlleva la realización de un conjunto de tareas a lo largo del ciclo de

vida del sistema. De acuerdo con el estándar IEEE 1012-1986
1 1986 el conjunto mínimo de pruebas
que se deben realizar son:
La prueba modular consiste en la prueba de cada módulo aislado del resto del sistema.
La prueba de integración se realiza a medida que los diferentes módulos del sistema se
integran en el mismo. Ya se ha realizado la prueba modular, y se supone que todos
módulos son correctos. El objetivo fundamental de esta prueba es comprobar que las
interfaces entre los distintos
distintos módulos son correctas. Algunas de las comprobaciones que
es necesario realizar son:
- Corrección en la sintaxis en la invocación de procedimientos y funciones.

- Compatibilidad de tipos entre los argumentos del procedimiento o función y los
parámetros de llamada.
l
- Corrección y completitud de las especificaciones de los módulos. Se pueden
utilizar tres posibles estrategias de integración:
- De arriba a abajo (top-down):
(top down): Consiste en empezar la integración y la prueba por
los módulos que están en los niveles superiores
superiores de abstracción, e integrar
ncrementalmente los niveles inferiores.
- De abajo a arriba (bottom-up):
(bottom up): Consiste en empezar la integración y la prueba por
los módulos que están en los niveles inferiores de abstracción, e integrar
incrementalmente los niveles superiores.
- De big-bang:
bang: Consiste en integrar y probar todo al mismo tiempo.
La prueba del sistema se realiza cuando se han integrado todos los módulos, y su objetivo
es comprobar que el sistema satisface los requisitos del usuario, tanto los funcionales
fun
como los no funcionales.
La prueba de aceptación se realiza una vez que el sistema se ha implantado en su entorno

real de funcionamiento, y su objetivo es demostrar al usuario que el sistema satisface sus
necesidades.

CALIDAD DE SOFTWARE
A continuación vamos a ver los dos grupos en que se clasifican los métodos de prueba:
- Métodos de caja negra

- Métodos de caja blanca
Métodos de caja negra
En este tipo de métodos, el objeto que se desea probar se ve como una caja negra. Esto
quiere decir que la elección de los casos de prueba no se va a basar en el conocimiento que
se tenga acerca de la estructura del objeto, sino en el conocimiento acerca de la funcionalidad
deseada (descripción funcional). A la prueba de caja negra también se le llama prueba
funcional o prueba
rueba orientada al diseño. Una prueba de caja negra exhaustiva requeriría la
generación de un caso de prueba por cada combinación posible (válida o no válida) de los
valores de entrada, lo cual resulta imposible en la mayor parte de los casos por producirse
producirs
una explosión combinatoria. Por eso se utilizan diferentes criterios a la hora de restringir el
conjunto de casos de prueba. Los métodos de selección del conjunto de casos de prueba más
usuales son:
Método de clases de equivalencia

Consiste en dividir las
las posibles entradas al sistema en clases de equivalencia, de tal
forma que todos los miembros de una misma clase de equivalencia prueben las
mismas propiedades en el sistema, por lo que sólo va a ser necesario seleccionar un
elemento de cada clase de equivalencia.
equi
Análisis de valores frontera o valores límite

Consiste en seleccionar como casos de prueba aquellos valores de entrada que caen

CALIDAD DE SOFTWARE
en la frontera de las clases de equivalencia (justo a un lado, justo al otro y justo en la

frontera).
Grafos causa/efecto
causa/ef y tablas de decisión
Consiste en crear un grafo causa/efecto a partir de las especificaciones, y seleccionar
suficientes casos de prueba como para asegurar la cobertura del grafo. Se llama
causas a las características de los datos de entrada y efectos a las clases de salidas
que puede proporcionar el programa. A partir del grafo causa/efecto se construye una
tabla de decisión que refleje las dependencias entre causas y efectos. Lo que se hace
entonces es reducir la tabla de decisión y seleccionar sólo un caso de prueba para
todas las causas que producen el mismo efecto, o para cada columna de la tabla de
decisión.
Adivinación de errores
Consiste en tratar de imaginar cuáles son los errores que se pueden haber cometido
con mayor probabilidad, y generar casos de prueba para comprobar dichos errores.
Métodos de caja blanca
En este tipo de métodos, el objeto que se desea probar se ve como una caja blanca. Esto
quiere decir que la elección de los casos de prueba se va a basar en el conocimiento que se
tenga acerca de la estructura del objeto (diseño detallado, diagramas de flujo de datos y de
control, código fuente). A la prueba de caja blanca también se le llama prueba estructural. Los
métodos de caja blanca se pueden clasificar, a su vez, en dos grupos: grupo Los basados en
métricas de cobertura y los basados en métricas de complejidad
1. Métodos basados en métricas de cobertura:
Todo programa se puede representar mediante un grafo de flujo de control, donde cada nodo
es una sentencia o una secuencia de sentencias.
sentencias. Los arcos dirigidos en el grafo representan el
flujo de control. Para cada conjunto de datos de entrada el programa se ejecutará a través de
un camino concreto dentro de este grafo. Cuando el programa incluye estructuras iterativas,
el número de posibles caminos en el grafo puede ser infinito. Una prueba de caja blanca
exhaustiva requeriría la generación de un caso de prueba por cada posible camino. Como esto
no es posible, por lo general, se utilizan métricas que dan una indicación de la calidad de un
determinado conjunto de casos de prueba en función del grado de cobertura del grafo que
consiguen. Las métricas más utilizadas son:
- Cobertura de sentencias
- Cobertura de segmentos entre decisiones.
- Cobertura de decisiones de ramificación
- Cobertura
rtura de condiciones
- Cobertura de todas las combinaciones de condiciones
- Cobertura de caminos
2. Métodos basados en métricas de complejidad:
Las métricas de complejidad más utilizadas en la generación de casos de prueba son las de
MacCabe:
- Complejidad ciclomática (arcos - nodos + 2 * número de componentes conexos)
- Complejidad esencial (complejidad ciclomática - número de subgrafos propios
de entrada y salida única)
- Complejidad real (número de caminos ejecutados)
Metodología de prueba
Cada
ada uno de los diferentes tipos de prueba implica la realización de un conjunto de
actividades estándar, así como la producción de un conjunto de salidas estándar.

CALIDAD DE SOFTWARE
Actividades Estándar de la Prueba Salidas Estándar asociadas

Planificación de la prueba. Plan de prueba.
Diseño de la prueba. Documento de diseño de la prueba.
Determinación de los casos de prueba. Especificación de los casos de prueba.
Planificación del procedimiento de prueba. Especificación del procedimiento de prueba.
Ejecución de la prueba. Informe de los casos de prueba.
Análisis y evaluación de prueba. Informe de la prueba.
1. Planificación de la prueba: Esta actividad consiste en la creación de un plan de

pruebas en el que se registra:
- El objetivo del proceso de prueba.
- Los objetos que hay que probar.
-Las
Las características que se van a probar y las que no.
- El método de prueba a utilizar.
- Los recursos que se van a emplear.
- El plan de tiempos.
- Los productos a generar durante las pruebas
- El reparto de las responsabilidades.
responsabilida
2. Diseño de la prueba: Esta actividad consiste en dar instrucciones detalladas acerca de:
- cómo llevar a cabo la prueba para alcanzar los objetivos deseados,
- de qué forma se van a utilizar los métodos de prueba,
- qué objetos se van a probar en cada
c una de las pruebas y
- qué criterios se van a utilizar para determinar si el objeto pasa o no pasa la prueba.
3. Determinación de los casos de prueba: Esta actividad consiste en especificar el

conjunto de casos de prueba a utilizar en función del diseño
diseño realizado para la prueba. Para
cada caso de prueba habrá que especificar:
- qué objetos se van a probar,

- qué entradas se les van a dar y
- cuáles son las salidas esperadas.
4. Planificación del procedimiento de prueba: Esta actividad consiste en fijar un

conjunto de pasos para la ejecución de la prueba. Se especifica detalladamente:
- la secuencia exacta de ejecución de los distintos casos de prueba,

- los requisitos que hay que cumplir para la ejecución de cada caso y
- las condiciones de terminación de cada uno de ellos.
5. Ejecución de la prueba: Esta actividad consiste en ejecutar cada caso de prueba, según
el procedimiento especificado en el paso anterior, y registrar los incidentes o problemas
encontrados durante la misma.
6. Análisis y evaluación de la prueba: Se examinan los resultados de la prueba y se decide si

se han alcanzado los objetivos propuestos o se debe repetir la prueba.
== FIN DE LA ASIGNATURA ==

Calidad de Software - Material de Estudio

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Calidad de Software - Material de Estudio

Uploaded by

Copyright:

Available Formats

ING. FELIPE ALIAGA CAVERO

UNIDAD DIDÁCTICA N° 01:

FUNDAMENTOS DE LA CALIDAD DEL SOFTWARE

UNIDAD DIDÁCTICA N° 02:

MODELOS Y ESTÁNDARES DE CALIDAD DE SOFTWARE

UNIDAD DIDÁCTICA N° 03:

MÉTRICAS DE CALIDAD DEL SOFTWARE

UNIDAD DIDÁCTICA N° 04:

EJECUCIÓN DEL CONTROL DE CALIDAD DE SOFTWARE

ING. FELIPE OMAR ALIAGA CAVERO 2

FUNDAMENTOS DE LA CALIDAD DE SOFTWARE

De acuerdo a la norma A3 – 1987 ANSI / ASQC, Calidad es la totalidad de aspectos

Debido a la gran variación de resultados de calidad, la búsqueda genuina del éxito en la

ING. FELIPE OMAR ALIAGA CAVERO 3

Los principios de gestión de la calidad total son sencillos de entender, pero

Los principios elementales son los siguientes:

Es cuando en una organización se determinan las actividades y los integrantes de la misma se

Análisis del concepto

Si se conocen los requisitos no se necesita supervisión, ya que se sabe qué hacer.

“lo están haciendo bien”

“brindar satisfacción total al cliente”

LA CLAVE DEL ÉXITO ES LA CALIDAD TOTAL DE MANTENER SISTEMÁTICAMENTE

ING. FELIPE OMAR ALIAGA CAVERO 4

El término calidad total es muy utilizado en los medios empresariales, políticos y

La ventaja comparativa de una empresa estaría en su habilidad, recursos, conocimientos y

El Concepto de Calidad Total tiene Cuatro Etapas:

¿Qué es Calidad Total?

• Potencialmente alcanzable si hay decisión del más alto nivel.

1. Cumplir con los requisitos. Para ello los directivos deben:

ING. FELIPE OMAR ALIAGA CAVERO 5

• Suministrar los medios necesarios

La calidad total en la organización de una empresa, debe ser el nervio y motor de

Los fundamentos de la calidad total son los siguientes:

Los obstáculos que impiden el avance de la calidad pueden ser:

ING. FELIPE OMAR ALIAGA CAVERO 6

Es el proceso de alcanzar los objetivos de calidad durante las operaciones. Para el

a) Elegir qué controlar.

El término calidad se ha convertido en una de las palabras clave de nuestra sociedad,

Pasos para poner en marcha el Control de Calidad

1. Establecimiento del compromiso

1. Establecimiento de la política de implementación del CTC y del programa para

ING. FELIPE OMAR ALIAGA CAVERO 7

1. Realización de eventos de educación, dirigidos a la alta dirección.

1. Una vez terminado el entrenamiento, "sacudida" de cada sección o departamento

ADMINISTRACIÓN POR POLÍTICA Y ESTANDARIZACIÓN.

1. Preparación de un borrador de administración por políticas, por parte de la oficina de

Diferenciaremos dos conceptos importantes como son:

• El control de calidad de sistemas está orientado a garantizar el funcionamiento de

La Ingeniería de Software concierne a teorías, métodos y herramientas para el desarrollo

La ISO (International Standard Organization), define La Calidad como la ausencia de

• El grado en el cual un sistema, componente

La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad,

Objetivo de la Calidad en los Sistemas

El Objetivo que persigue la Calidad en los Sistemas está orientada a:

• Incrementar la productividad y satisfacción al trabajo de los profesionales afines al

ING. FELIPE OMAR ALIAGA CAVERO 9

• Realizar una planeación eficaz de los sistemas.

Obtención de un Software de Calidad

• El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del

Control de Calidad del Software

ING. FELIPE OMAR ALIAGA CAVERO 10

1. Definir el software que va a ser controlado:

• Ell acercamiento a cero defectos.