Unidad 1 Fundamentos Del Aseguramiento de La Calidad Del Software PDF

Pruebas y mantenimiento de sistemas de software
Unidad 1. Fundamentos del aseguramiento de la calidad del software
Ingeniería en Desarrollo de Software

8º Semestre
Programa de la asignatura:
Unidad 1. Fundamentos del aseguramiento de la calidad

del software
Clave:
15144832
Universidad Abierta y a Distancia de México

UnADM
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 1

Índice
Unidad 1. Fundamentos del aseguramiento de la calidad del software .............................. 3

Propósitos.......................................................................................................................... 4
Competencia específica..................................................................................................... 4
1.1. Calidad del software en el entorno de las organizaciones ........................................... 4
1.1.1. Estándares internacionales: ISO e IEEE .................................................................. 6
1.1.2. Modelos y procesos para garantizar la calidad del software................................... 14
1.1.3. Ciclo de vida del software y ámbitos de análisis de la calidad ................................ 18
Actividad 1. Objetivos del aseguramiento de la calidad del software ................................ 23
1.2. Aseguramiento de la calidad del software ................................................................. 23
1.2.1. Estándares para el aseguramiento de la calidad del software ................................ 28
Actividad 2. Estándares del aseguramiento de la calidad del software ............................ 32
1.2.2. SQA (software quality assurance) .......................................................................... 32
Autoevaluación ................................................................................................................ 39
Evidencia de aprendizaje. Aseguramiento de la calidad del software .............................. 39
Autorreflexiones ............................................................................................................... 39
Cierre de la unidad .......................................................................................................... 40
Para saber más ............................................................................................................... 41
Fuentes de consulta ........................................................................................................ 41

Presentación de la unidad
¿Te has preguntado alguna vez por qué un cierto programa no funciona como quieres?, o
quizás, ¿cómo puede existir software comercial que presenta errores? Las respuestas a
estas interrogantes están directamente relacionadas con la calidad de dichos productos, y
en esta unidad encontrarás un panorama introductorio a los temas que definen la forma
en la que podrás garantizar la calidad de cada uno de tus desarrollos en sus diferentes
ámbitos, lo cual tiene el propósito de aportar a tu formación profesional como
desarrollador de software, el tener en mente que la calidad debe estar presente en todas
las fases de desarrollo de sistemas. En esta unidad se revisará el marco de referencia de
las pruebas y mantenimiento de sistemas de software como parte importante del
aseguramiento de la calidad.
Un sistema de software, según Campderrich (2013):
Es un conjunto de programas que en su forma definitiva se pueden ejecutar, pero comprende también
las definiciones de estructuras de datos […] que utilizan estos programas y también la documentación
referente todo ello tanto la documentación de ayuda en el uso del software para sus usuarios como la
documentación generada durante su construcción, parte de la cual también servirá para su
mantenimiento posterior (p.15).
Los fundamentos del aseguramiento de la calidad del software son un marco de

referencia para el desarrollo de las siguientes unidades, pues las pruebas y el
mantenimiento del software son aspectos que garantizan la calidad porque “antes de
poner el sistema en funcionamiento, es necesario probarlo. Es mucho menos costoso
encontrar los problemas antes que el sistema se entregue a los usuarios” (Kendall y
Kendall, p.12), considerando que el objetivo principal del aseguramiento de la calidad de
software es la satisfacción del cliente.
En el tema 1.1. Calidad del software en el entorno de las organizaciones, realizarás un

repaso de los estándares internacionales ISO e IEEE que evalúan la calidad de los
sistemas de software, mismos que revisaste a detalle en la asignatura Modelos de calidad
de software, con el fin de identificar los estándares relacionados con las pruebas y
mantenimiento de los sistemas. En el tema 1.2. Aseguramiento de la calidad del software,
revisarás lo referente a los modelos y procesos que se aplican para garantizar la calidad;
de igual manera, retomarás los conceptos del ciclo de vida del software a partir del
concepto de ciclo de vida de software, que ya revisaste en asignaturas anteriores como
Diseño y arquitectura de software o Desarrollo de software en equipo TSP, para aprender
de qué manera es posible integrar el ámbito de la calidad en cada una de sus fases,
enfatizando las fases de pruebas y mantenimiento de sistemas de software.

Propósitos
Al término de esta unidad lograrás:
 Identificar los procesos que garantizan la calidad del software durante las
diferentes fases su ciclo de vida.
 Comprender el alcance, la importancia y la aplicación de los estándares que
evalúan la calidad del software.
 Identificar la importancia de los marcos de referencia para desarrollar softwares
bajo un esquema de calidad.
 Identificar el marco de referencia de las pruebas y mantenimiento de los sistemas
de software en relación con la calidad.
Competencia específica
 Analizar los procesos que garantizan la calidad del software para determinar los
requerimientos de pruebas y mantenimiento, mediante los estándares de calidad.
1.1. Calidad del software en el entorno de las organizaciones
En la actualidad, todas las organizaciones requieren el apoyo de la tecnología para llevar

a cabo la mayoría de sus procesos. Los sistemas de software se han vuelto parte
fundamental de la vida de toda organización, y han cobrado tal importancia que su
funcionamiento puede marcar las pautas para el crecimiento o la caída de dichas
organizaciones, por este motivo, los procesos de análisis y evaluación de la calidad están
tomando mayor importancia para la industria de desarrollo de software, debido a que un
software de calidad representa una ventaja competitiva muy poderosa que puede
significar la mejora continua de toda la organización, así como el cumplimiento de sus
objetivos institucionales.
En esta primera unidad se expondrán los fundamentos de la calidad del software y la

importancia de su aplicación en el desarrollo de sistemas, incluyendo los estándares
internacionales más relevantes de la evaluación de la calidad del software como marco de
referencia para establecer los requerimientos de un proyecto de pruebas y mantenimiento.

Para poder definir el concepto de calidad del software, es necesario analizar previamente
las diferentes connotaciones y definiciones que existen sobre ella en ámbitos más
generales.
Para Calero et ál. (2010), la definición del concepto de calidad del software no debe
abarcar únicamente al propio producto o componente de software en sí, sino a todo el
contexto que rodea a dicho producto o componente. De acuerdo con el autor, este
enfoque de calidad (incluso aplicada a cualquier cosa) debe tener una visión integral, que
contemple el entorno donde se ejecuta y los procesos que lo han generado.
Según Chemuturi (2011, p. 2), la calidad puede apreciarse desde tres perspectivas:
 Para un consumidor final, la calidad connota una funcionalidad libre de defectos, fácil
de usar, con niveles aceptables de fallas durante su uso, confiable en su rendimiento,
con fácil acceso a servicios y protección contra daños.
 Para un productor de bienes, la calidad connota la conformidad con las

especificaciones del producto, definidas por el propio productor, una asociación
industrial o el gobierno.
 Para un proveedor de servicios, la calidad connota proporcionar sus servicios en el

tiempo acordado, de acuerdo con las especificaciones requeridas por el cliente.
Como es posible observar, la calidad tiene diferentes connotaciones, según los actores
organizacionales.
La norma ISO 9000:2000 define a la calidad como “el grado en el que un conjunto de
características inherentes cumple con los requerimientos” (Uddesh, p. 308). En la
definición anterior, se entiende como grado un nivel continuo de calidad que comienza en
cero y crece quizá infinitamente. Esta deducción, sin embargo, es ambigua debido a que
se puede cuestionar lo siguiente: ¿en qué nivel se considera la calidad como mala, buena
o excelente?, ¿quién está facultado para emitir esta calificación? Existen estándares
internacionales y proyectos de aseguramiento de la calidad del software, mismos que se
detallarán a continuación.
La importancia de la calidad del software va en aumento en cuanto al desarrollo de

sistemas de software, debido principalmente a que un sistema que se desarrolla siguiendo
los modelos de calidad representará una ventaja competitiva de la organización para la
cual está dirigido, ofreciendo mejores servicios y productos para los consumidores.

En el tema 1.1. Calidad del software en el entorno de las organizaciones, se abordarán los
ámbitos de análisis de la calidad de los sistemas de software, así como los estándares
internacionales que rigen el proceso del aseguramiento de la calidad.
Esta unidad comprende el estudio de los estándares internacionales ISO e IEEE. Tema
que aporta los lineamientos estandarizados para construir software de calidad.
Posteriormente, se analizarán los modelos y procesos que se emplean para garantizar la
calidad del software, mediante una introspección a la forma en la que se abordan cada
una de las fases de desarrollo de software, y se podrá identificar el nivel de madurez de
las actividades encaminadas a la calidad. Finalmente, en el tema sobre el ciclo de vida del
software y los ámbitos de análisis de la calidad, se abordarán las cuatro dimensiones que
definen un software de calidad y cómo se relacionan con el ciclo de vida de los sistemas.
Comprender los temas de esta unidad es importante debido a que se introduce la calidad
al ciclo de vida de sistemas como un complemento a cada una de sus diferentes fases;
esto con el objetivo de que los proyectos de desarrollo de software, elaborados bajo un
enfoque de calidad, cubran eficientemente los requerimientos para los cuales fueron
concebidos.
1.1.1. Estándares internacionales: ISO e IEEE
En el ámbito de las pruebas y mantenimiento de sistemas de software, los estándares

internacionales juegan un papel fundamental, debido a que ofrecen lineamientos de
calidad que habrán de seguirse para cubrir correctamente los requerimientos de los
proyectos. Este tema tiene mucha importancia en el entorno de las organizaciones debido
a que los conceptos de calidad y estándar se relacionan muy estrechamente. De acuerdo
con Llorens (2005), un estándar se refiere a la definición de las características que debe
cumplir cada elemento que conforma un sistema de software, y si son cumplidas de
acuerdo con las recomendaciones del propio estándar, es posible pronosticar que el
proceso será efectuado con calidad.
En la actualidad, las organizaciones con mayor renombre son aquellas que han integrado
la calidad como parte básica de sus procesos. La implementación de normas y
estándares puede ser un deber largo y tedioso para una organización, principalmente por
los recursos implicados en el proceso de certificación, compromiso público que una
organización hace con la calidad al cubrir los lineamientos especificados en los diferentes
estándares internacionales. Cuando una organización cuenta con una o varias
certificaciones, éstas se traducen en garantías para sus usuarios (Calero et ál., 2010).

Esta inversión en recursos toma sentido cuando se evalúan las ventajas que representa la
adopción de las normas o estándares internacionales de calidad de los productos o
servicios de una organización, entre las que se encuentran el mejorar los procesos de la
organización, la reducción de costos, mejora en el control del negocio, mejora en la
generación de información para la toma de decisiones, entre otras. Cada una de las
mencionadas anteriormente, pueden ser aplicadas también en los proyectos de desarrollo
de software.
Según se revisó en la asignatura Modelos de calidad de software, existen dos grandes

organizaciones que regulan y emiten los estándares para la evaluación del software con
mayor aceptación en el mundo: el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE)
y la Organización Internacional de Normalización (ISO por sus siglas en inglés). Dichas
organizaciones han emitido y actualizado diferentes normas que ayudan a los equipos de
desarrollo de software a efectuar y medir su trabajo bajo un enfoque de calidad.
Debido a que existen numerosas familias de normas que evalúan diferentes áreas del
desarrollo de software, esta unidad se enfocará en las más representativas para los
procesos de pruebas y mantenimiento, mismas que son fundamentales para que un
producto de software pueda ser considerado de calidad.
Norma ISO/IEC 25000:2005 Software product Quality Requirements and Evaluation

(SQuaRE)
La familia de normas ISO/IEC 25000:2005 es una evolución de la ISO 9126.
El siguiente esquema representa la forma en la que se clasifican las diferentes categorías

y subcategorías para la evaluación de la calidad del software que integran la familia de
normas ISO 9126.

Categorías Subcategorías
Adecuación
Funcionalidad Precisión
Interoperabilidad
Seguridad
Conformidad de su funcionalidad
Madurez
Confiablidad Tolerancia a fallas
Habilidad de recuperación
Conformidad de su confiablidad
Clasificación de
Comprensibilidad
las categorías y
Usabilidad Facilidad de aprendizaje
subcategorías de
Facilidad de operación
la norma ISO
9126 Conformidad de su usabilidad
para la
evaluación del Manejo de tiempos
software Eficiencia Empleo de recursos
Conformidad de su eficiencia
Facilidad de ser analizado

Facilidad de Facilidad de mantenimiento y
mantenimiento cambios
Estabilidad
Conformidad del mantenimiento
Adaptabilidad
Portabilidad Facilidad de instalación
Coexistencia
Facilidad de reemplazarse
Conformidad de la portabilidad
Categorías y subcategorías de ámbitos para la evaluación de la calidad del software. Basado en Carrol, 2007,
p. 200.
Como complemento a la norma ISO/IEC 9126-1 existe la ISO/IEC 9126-2, que

proporciona métricas externas para la medición de las seis características mencionadas
anteriormente (funcionalidad, confiabilidad, usabilidad, eficiencia, facilidad en el
mantenimiento y portabilidad), mientras que ISO/IEC 9126-3 define las métricas internas e

ISO/IEC 9126-4 la calidad en el uso de las métricas para de la medición de las

características y subcaracterísticas.
Las métricas internas son aquellas que miden la calidad del software considerando
factores medibles durante su desarrollo (por ejemplo, el tiempo en el progreso de cada
fase, las líneas de código, etcétera), mientras que las métricas externas evalúan la calidad
del software teniendo en cuenta los resultados de utilizarlo en un ambiente de producción.
Calero et ál. (2010) señalan que:
Los factores externos, son todos aquellos factores que pueden ser directamente percibidos por los
usuarios y que afectan su trabajo (usualmente relacionadas a la funcionalidad y usabilidad). Factores
internos, hacen referencia al as características constructivas de los componentes, que son tan sólo
accesibles y controlables por sus fabricantes. No todas las propuestas existentes separan de esta
forma los factores pero sí se aplica en el estándar ISO/IEC 9126 y en los modelos resultantes de
aplicar el método SQUID (p. 297).
La evolución de familias de normas enfocadas en la calidad del software (especialmente

la 9126), dio como resultado el surgimiento de una nueva y consolidada familia, la
ISO/IEC 25000 conocida como SQuaRE, que son requisitos de calidad y evaluación de
productos de software (por sus siglas en inglés de Software Product Quality Requirements
and Evaluation).
La familia de normas 9126 evolucionó para consolidarse en la 25000. Presenta, entre

otras, las siguientes mejoras (Calero et ál., 2010, p. 628):
 Mejor coordinación de la guía en la medición y evaluación de la calidad de los

productos de software
 Mejor orientación para la especificación de requisitos de calidad de los productos
de software
 Mejor distinción entre las partes beneficiarias de un producto de software
 Incorporación y revisión de un modelo de calidad para los datos
 Incorporación y revisión del proceso de evaluación
 Renombramientos de las categorías y subcategorías para evitar ambigüedades.
La familia ISO/IEC 25000 se compone de cinco divisiones principales (Calero et ál., 2010):
1. ISO/IEC 2500n–División de Gestión de Calidad. Las normas ISO/IEC 2500n

establecen todos los modelos, términos y definiciones comunes referenciados por
todas las otras normas de la familia 25000.

2. ISO/IEC 2501n–División de Modelo de Calidad. Este apartado presenta modelos

de calidad detallados, incluyendo características para calidad interna, externa y en
uso del producto software.
3. ISO/IEC 2502n–División de Medición de Calidad. Incluye un modelo de referencia

de la medición de la calidad del producto, definiciones de medidas de calidad
(interna, externa y en uso) y guías prácticas para su aplicación.
4. ISO/IEC 2503n–División de Requisitos de Calidad. Ayudan a especificar los

requisitos que pueden ser utilizados en el proceso de obtener requisitos de calidad
del producto software a desarrollar, o como la entrada del proceso de evaluación.
5. ISO/IEC 2504n–División de Evaluación de Calidad. Incluye normas que

proporcionan requisitos, recomendaciones y guías para llevar a cabo el proceso de
evaluación del producto software.
Los estándares ISO para el desarrollo de software siguen modelos similares a los del ciclo
de vida del software, por eso es posible decir que la búsqueda de la calidad comienza
desde el inicio del propio proyecto, y lo acompaña durante todo su desarrollo.
Si se desea implementar el estándar ISO/IEC 25000, es necesario contemplar los

siguientes tres enfoques:
1. Enfoque interno: ayuda a detectar deficiencias en el producto de software desde

sus fases iniciales. Incluye la obtención de los requerimientos y su análisis, la
propuesta de diseño que cubra los requerimientos, todo el código fuente y
aplicaciones, así como sus pruebas implementación, puesta en marcha y
mantenimiento.
2. Enfoque externo: considera que el software ya se está ejecutando o que está en
un ambiente de producción, pues es sólo hasta este momento cuando se puede
analizar realmente si los resultados generados son los mismos que los esperados.
3. Enfoque en uso: ayuda a medir la calidad del software frente a una operación por
los usuarios finales. Esto debido a que el software puede tener resultados
incorrectos si ocurrió un error durante el diseño de las interfaces e interacciones
con el usuario.
Para el ámbito de las pruebas y mantenimiento de software, esta familia de normas tiene
mucha relevancia debido a su relación directa con las fases de pruebas y mantenimiento
de software, debido a que las normas SQuaRE evalúan la calidad del software desde dos
perspectivas, la interna y la externa (uso del producto).

Las características internas que se relacionan directamente con las pruebas de sistemas
de software abarcan cada una de las descritas anteriormente: funcionalidad, confiablidad,
usabilidad, eficiencia, facilidad de mantenimiento y portabilidad. Las características
externas también figuran directamente en los procesos de pruebas de sistemas de
software; es en ellas donde tienen mayor peso las pruebas, pues es cuando el producto
final es sometido a dichas evaluaciones.
El mantenimiento de software entra en juego como parte de las características internas de

facilidad de mantenimiento pues, como su nombre lo indica, se enfoca en la capacidad
que tiene el software de ser modificado y aceptar procesos de mantenimiento.
Puedes conocer más información sobre la familia ISO/IEC 25000 y sus subdivisiones la
página electrónica de ISO 25000 Calidad del producto software.
Estándar IEEE 12207
El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) también cuenta con diferentes

estándares que evalúan la calidad de un producto o sistema de software. Para efectos de
esta asignatura, se revisará el estándar IEEE 12207 propio de las tecnologías de la
información, que establece un marco de referencia común para el ciclo de vida de
sistemas (IEEE, 2008).
El campo de aplicación de este estándar es muy amplio en los sistemas de software, y de

igual manera que con las normas ISO revisadas anteriormente, las pruebas y
mantenimiento de software son contempladas por estas métricas de calidad.
De acuerdo con Tuya et ál. (2007), la norma IEEE 12207 agrupa los procesos del ciclo de
vida del software en tres niveles principales, que a su vez se dividen en otras categorías
de proceso (p. 19):
1. Procesos primarios. Se componen de las siguientes categorías:
 Adquisición. Procesos que realiza el cliente para la adquisición de un producto o

servicio.
 Suministro. Comprende los procesos realizados por un proveedor, desde la
propuesta hasta la entrega de un bien o servicio.
 Ingeniería. Agrupa a los procesos que directamente especifican, implementan o
mantienen el producto software, así como su relación con el sistema y la
documentación con el cliente.
 Operación. Se refiere a los procesos relacionados con el funcionamiento del
producto, y se ocupa del correcto uso y operación del mismo.

2. Procesos de soporte. Se refiere a los procesos que pueden ser empleados por
cualquiera de los otros procesos en determinadas fases del ciclo de vida.
3. Procesos de la organización. Se componen de las siguientes categorías:
 Gestión. Comprende los procesos que contienen prácticas que pueden ser utilizadas
por cualquier persona que gestione cualquier tipo de proyecto, o de proceso del ciclo
de vida del software.
 Mejoramiento. Comprende los procesos que establecen, definen, implementan,
evalúan y mejoran las técnicas que se realizan en la organización.
 Infraestructura. Describe los métodos que se realizan para dotar a la organización
tanto de capital humano como de la infraestructura necesaria para que los otros
procesos puedan realizarse de manera apropiada.
 Reutilización. Contiene los procesos directamente relacionados con la realización de
acciones destinadas a explotar las oportunidades de reutilización.
Las pruebas de software se encuentran presentes en los procesos primarios y de soporte

del ciclo de vida. Este tema será visto a detalle en la siguiente unidad; sin embargo, es
importante resaltar la fase de pruebas de software como un paso fundamental en la
búsqueda de la calidad (se revisará con más detalle lo que respecta a las pruebas de
software en la Unidad 2. Pruebas de sistemas de software). En los procesos primarios se
localizan las pruebas de software como parte del ciclo de vida de sistemas, y en los
procesos de soporte toma también importancia como parte del aseguramiento de la
calidad, verificaciones, validaciones, revisiones y auditorías.
El mantenimiento de sistemas de software es parte también de esta norma, y se le puede

localizar en el proceso primario del ciclo de vida como uno de los subprocesos más
importantes. De igual manera, se encuentra presente en los procesos organizaciones del
ciclo de vida como parte fundamental del subproceso de mejoramiento.

Procesos primarios del ciclo de vida Procesos de soporte del ciclo de vida
Adquisición Documentación
Suministro Gestión de la configuración
Aseguramiento de la calidad
Verificación
Validación
Ingeniería Operación
Revisión conjunta
Auditoría
Resolución de problemas
Procesos organizacionales del ciclo de vida

Gestión Infraestructura
Mejoramiento Reutilización
Estructura del estándar IEEE 12207. Fuente Tuya et ál., 2007.
El diagrama anterior muestra los principales procesos que se evalúan en el estándar, así
como los subprocesos que los conforman.
Los estándares que se analizaron en esta unidad comprenden los más relevantes para las
fases de pruebas y mantenimiento de sistemas de software. Es importante su
conocimiento, debido a que representan un marco de referencia para encaminar el
desarrollo de software hacia mejores niveles de calidad.
El siguiente paso para desarrollar software de calidad es adentrarse en los procesos que
se llevan a cabo durante un proyecto, para identificar si se están realizando de la manera
correcta y, en caso contrario, se optimice su ejecución.
Si deseas consultar más información acerca de los estándares que creó la IEEE para la
ingeniería de software, ingresa a la página electrónica de la IEEE Standards Association.

1.1.2. Modelos y procesos para garantizar la calidad del software
En el tema anterior se analizaron algunos de los estándares internacionales más

importantes para el desarrollo de software. Para continuar con este enfoque de calidad, es
necesario analizar los modelos que son empleados para evaluar los procesos implicados
en el ciclo de vida del desarrollo de sistemas de software, con el objetivo de identificar sus
fortalezas y debilidades, para después plantear una serie de actividades de control y
revisión que mejoren dichos procesos.
Cuando se conocen a fondo los procesos de desarrollo de software y se han

estandarizado, el seguimiento a la implementación mediante proyectos de pruebas y
mantenimiento será más eficiente frente a un escenario donde no existan antecedentes
de análisis de procesos o el empleo de estándares.
El desarrollo de software ha tenido una constante y acelerada evolución a lo largo del

tiempo, basta con recordar a la primera generación de lenguajes de programación
(lenguajes máquina) y compararla con las últimas, que permiten desarrollar software de
inteligencia artificial, para identificar que existe una diferencia notable.
Esta evolución ha respondido siempre a la demanda de los sistemas de software por

parte de los usuarios y es posible, de acuerdo con Tuya et ál. (2007), identificar tres
etapas:
Primera etapa. En la década de los 70, el crecimiento tan acelerado de la demanda y de

la complejidad del software, por parte de los usuarios y organizaciones, provocó que los
equipos de desarrollo comenzaran a cambiar. En esta fase se seguían los paradigmas de
métodos estructurados y el ciclo de vida en cascada. Una de las principales aportaciones
al proceso de desarrollo de software fue la introducción de la representación de los
procesos de desarrollo por medio de diversos diagramas. Esta serie de cambios y
adaptaciones a la demanda iniciaron el camino del desarrollo de software hacia su
transformación en una ingeniería.
Segunda etapa. Se distingue por el movimiento de madurez de los procesos implicados

en el desarrollo de software. Responde a una iniciativa del gobierno de los Estados
Unidos para desarrollar métodos para la evaluación de sus proveedores de software,
quienes fundaron el SEI (Software Engineering Institute), para desarollar un método de
evaluación de la capacidad de sus proveedores. Estas investigaciones corrieron a cargo
de Watts Humphrey, quien identificó que todos los procesos de desarrollo de software
pueden ser susceptibles de contar con evaluaciones de calidad, tal como sucede en las
líneas de producción de cualquier industria. El principio básico de Humphre es la
"orientación a procesos, vista como la necesidad de contemplar todas las tareas
relacionadas con el desarrollo de software, como un proceso que puede ser controlado,
medido y mejorado” (Humprey, citado en Tuya et ál., 2007, p. 8). De esta manera fue que

se incorporaron al desarrollo de software los principios de calidad existentes, propuestos

por Edwards Deming y Philip Crosby, quienes habían trabajado en una serie de
lineamientos para las industrias de producción.
El principal cambio de paradigma en esta etapa radica en que la evaluación de la calidad

ya no se realizará únicamente a niveles del ciclo de vida de sistemas (análisis, diseño o
implementación), debido a que se contemplan también aspectos de gestión del proyecto y
procesos de soporte.
La comparación del desarrollo de software con una línea de producción de una fábrica
podría parecer que le resta ese carácter artesanal, con el que a muchos desarrolladores
de software les gusta comparar su trabajo; sin embargo, esta analogía es necesaria para
lograr una mejor medición de la calidad.
Tercera etapa. Aquí es posible hablar ya de una industrialización del software, donde se
contempla el uso de tecnologías de orientación a objetos y reutilización de librerías, bajo
un esquema de procesos bien delimitados para la ingeniería del software. Comienza el
auge de la producción masiva de software calidad.
Como en las demás industrias, el desarrollo de software no pasó desapercibido para los
estándares, y comenzó el desarrollo y evolución de las normas que evalúan la calidad de
los sistemas de software.
Capability maturity model (Modelo CMM)
Fue desarrollado a principios de los años 90 por el SEI (Software Engineering Institute),
institución creada por el gobierno estadounidense, mencionada en la etapa dos de la
evolución del desarrollo de software, bajo el liderazgo de Watts Humprey (Tuya et ál.,
2007), con la finalidad de contar con un marco de referencia para la evaluación y mejora
de procesos de software.
El modelo CMM divide la madurez de los procesos de software en cinco fases o niveles,
que buscan un refinamiento continuo hacia la optimización de cada proceso. Por madurez
de los procesos de software debe entenderse el nivel en el que se encuentra el software,
de acuerdo con la siguiente escala evolutiva, representada en la siguiente gráfica:

Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5

Inicial Repetible Definido Gestionado En optimización
Niveles del modelo CMM. Basado en Tuya et ál., 2007.
Cada uno de los niveles del CMM se define por una serie de áreas clave de proceso o
KPA (key process área, por sus siglas en inglés). De acuerdo con Tuya et ál. (2007),
estas KPA se refieren a un grupo de actividades que al ser realizadas por el equipo de
desarrollo de software de manera conjunta, ayudarán a lograr los objetivos de su nivel y
encaminarlo al proceso el estado más alto de madurez.
Es posible definir a las KPA como el conjunto de estrategias que se deben llevar a cabo,
en cada niel del CMM, para lograr el nivel de madurez requerido y avanzar al siguiente.
Éstas son descritas a continuación:
Nivel 1 inicial. Se caracteriza por la indisciplina en los procesos. No cuenta con áreas
clave de proceso o KPA (Tuya et ál., 2007).
Nivel 2 repetible. Comprende la gestión de la configuración del software, el SQA

(aseguramiento de la calidad del software). Se incluyen las cuestiones administrativas
inherentes a un proyecto de desarrollo de software, tales como su planificación, desarrollo
y control. Adquiere el nombre de repetible debido a que se logran procesos estables, con
niveles aceptables de control y estandarización (Tuya et ál., 2007).
Nivel 3 definido. Contempla la ingeniería del producto de software. Recibe el nombre de

definido debido a que ya se cuenta con procesos predecibles. Se incluye un estudio a
detalle de todos los procesos, así como la coordinación del grupo de desarrollo de
software (Tuya et ál., 2007).
Nivel 4 gestionado. Contempla la mejora continua de los procesos, toda vez que ya se
han superado los niveles anteriores. Para efectuar esta acción, se incluyen los conceptos
de gestión de la calidad del software y la cuantitativa de procesos (Tuya et ál., 2007).

Nivel 5 en optimización. Una vez que se ha alcanzado un nivel optimizado, es necesario

permanecer en él; por lo tanto, este nivel comprende la gestión del cambio en los
procesos, de tal manera que no afecten los logros que ya se han obtenido. También
contempla la gestión de los cambios tecnológicos, pues es muy común que una mejora en
la tecnología permita otra en los procesos; por ejemplo, los sistemas basados en la nube
que se desprendieron de un equipo físico para estar disponibles en Internet, permiten
interactuar con ellos desde cualquier punto con acceso a la red, distribuyendo en tiempo
real los datos sensibles para los usuarios de dicho sistema (Tuya et ál., 2007).
Evolución del CMM hacia el CMMI

A lo largo de este curso, se ha mencionado en constantes ocasiones que el desarrollo de
software y los aspectos tecnológicos se encuentran en constante evolución; el CMM no ha
sido la excepción y, siguiendo su propia naturaleza de mejora continua, ha evolucionado
para lograr un mejor control de procesos.
EL CMMI o modelo de madurez de capacidades integrado (capability maturity model

integration, por sus siglas en inglés), surgió para solucionar inconsistencias de la
arquitectura, enfoque, contenido y aplicación con que se encontraban las organizaciones
que buscaban la implementación del CMM (Tuya et ál., 2007).
Los tres ejes fundamentales del surgimiento del CMMI son la reorganización de áreas de
proceso, la mejora y modernización de las KPA, así como la creación de objetivos
genéricos para cada área de proceso, lo que facilita que se entienda bien el fin que tiene
cada nivel del CMMI (este modelo se revisó a detalle en la asignatura Modelos de calidad
de software).
En este tema se analizaron los modelos y procesos que se emplean para garantizar la
calidad del software. El principal objetivo de este estudio es llevar la calidad a lo más
profundo del desarrollo: sus procesos. Las pruebas y mantenimiento de sistemas de
software tienen una relación muy cercana con estos procesos, pues para determinar si
están dando el resultado adecuado es necesario ponerlos a prueba, y de acuerdo con los
resultados, establecer si es necesaria la implementación de proyectos de pruebas y
mantenimiento, tanto de los procesos como del desarrollo completo.
Es importante recordar que la calidad del software va mucho más allá de si este cubre con
los requerimientos del usuario, también es importante que la calidad se refleje en la
documentación del proyecto, su administración, el código fuente, la selección y
capacitación del personal de desarrollo.

1.1.3. Ciclo de vida del software y ámbitos de análisis de la calidad
El ciclo de vida del software se refiere a los procesos o fases implicadas en su desarrollo.
Existen diferentes tipos de modelos que definen su ciclo de vida, tales como el modelo en
cascada, el basado en componentes, el modelo del desarrollo evolutivo, entre otros, los
cuales revisaste en la asignatura Métodos y modelos de desarrollo de software.
Sin importar el modelo empleado para el ciclo de vida de los sistemas de software, es
posible apreciar fases fundamentales en cada uno de ellos, tales como (Sommerville,
2011):
 Especificación del software. Son definidas las funciones del software así como sus
alcances y limitaciones.
 Diseño e implementación del software. Se produce el software descrito en la
especificación.
 Validación del software. Valida que el software realice los procesos de acuerdo con
la forma en que se espera que lo haga.
 Evolución del software. Son definidos los cambios o adaptaciones que el software
debe realizar para ajustarse a las necesidades cambiantes de los usuarios.
Como se mencionó anteriormente, existen diferentes modelos para el desarrollo de

sistemas de software y, en todos los casos, cada proceso involucrado en el desarrollo es
susceptible de ser mejorado; esto se logra mediante la estandarización de los procesos.
Los principales beneficios que esta actividad representa para una organización son:
mejoras en la comunicación, reducción de tiempos de desarrollo, reducción de recursos,
así como la implementación de nuevos métodos, técnicas y buenas prácticas de
ingeniería de software.
Cualquiera que sea el modelo que se emplee en un proyecto de desarrollo de software, el

concepto de calidad puede ser implementado en cada una de sus fases.
Para Calero et ál. (2010), en el estudio de la calidad del software es posible apreciar las
mismas estructuras que en un ciclo de vida de sistemas de software. Desde la obtención
de los requerimientos (análisis), integración de componentes (desarrollo) hasta el
mantenimiento del sistema.
De acuerdo con Chemuturi (2010, p. 25), existen cuatro ámbitos de análisis de la calidad
que definen las fases principales del ciclo de vida de los sistemas de software:
1. Calidad de la especificación
2. Calidad del diseño
3. Calidad en el desarrollo
4. Calidad de la conformidad

Los ámbitos de análisis de la calidad se aplican de manera paralela al ciclo de vida del
software:
Calidad de la especificación. Se ubica en la primera fase del ciclo de vida del software,
en la fase de análisis.
Calidad del diseño. Se ubica en la segunda fase del ciclo de vida del software, en la
etapa de diseño.
Calidad en el desarrollo. Se ubica en la tercera fase del ciclo de vida del software, en la
etapa de desarrollo.
Calidad de la conformidad. Se ubica en la cuarta fase del ciclo de vida del software, en
la fase de pruebas.
A continuación, se describe cada una de las dimensiones o ámbitos de análisis de la

calidad del software:
1. Ámbito de la calidad del software: especificación. La primera fase de la calidad de

software es la de análisis (Sommerville, 2011). En ésta, el ámbito de análisis de calidad
de software es la especificación de los requerimientos. La calidad de la especificación se
refiere a qué tan bien han sido definidos los requerimientos para el producto o servicio
que se presta. Se trata de un punto crucial debido a que no existen actividades
predecesoras, y el resto del desarrollo partirá de dichas especificaciones. Esta verificación
es llevada a cabo en la fase de análisis del desarrollo de sistemas (Chemuturi, 2010).
Dentro del ciclo de vida tradicional del software, las especificaciones forman parte de la
fase del análisis, y si no son definidas de manera correcta, el diseño será incorrecto y
provocará que el producto final también sea incorrecto. Cualquier esfuerzo gastado en el
aseguramiento de la calidad será en vano.
Es de suma importancia que las especificaciones de los sistemas de software sean bien
definidas, comprensibles, y que tomen en cuenta todos los aspectos posibles que se
relacionan con la calidad del sistema.
Tipo de Aspectos que comprende el tipo de especificación

especificación
Se refiere a las funciones que deben ser logradas; es decir, la
Funcionalidad descripción de los procesos que puede realizar el software.

El ejemplo de un aspecto de funcionalidad puede ser el área de

administración escolar de una universidad, la cual requiere que los
alumnos puedan inscribirse a sus cursos a través de un portal vía
Internet. La funcionalidad en este ejemplo es la inscripción de
alumnos.
Especifica la carga que el producto o servicio de software debe
soportar, de acuerdo con los requerimientos.
Capacidad Si se retoma el caso anterior, un ejemplo de un aspecto de
capacidad consiste en que se puedan inscribir, de manera
concurrente, hasta un máximo de 100 alumnos por minuto.
Especifica las necesidades que el producto o servicio va a

satisfacer.
Uso
A partir del caso de la universidad, un aspecto de uso es
automatizar el proceso de inscripciones.
Especifica el tiempo en el que el producto o servicio podrá ser

usado antes de requerir mantenimiento.
Confiabilidad Un aspecto de confiabilidad consiste en que la misma universidad
requiere que el sistema funcione correctamente por un mínimo de
dos semestres, sin necesidad de mantenimiento.
Especifica los niveles límite para asegurar a los usuarios el uso

del producto o servicio. Señala cualquier amenaza para la cual el
producto o servicio deba prepararse.
Seguridad
Un aspecto de seguridad consiste en que el sistema de
inscripciones debe ofrecer sus servicios sin interrupciones,
además de estar bien protegido en contra de cualquier tipo de
ataque informático.
Aspectos comprendidos por cada tipo de especificación para que la obtención de requerimientos sea de
calidad. Basado en Chemuturi, 2010.
Para asegurar que las especificaciones sean correctas, es necesario que personal
altamente calificado en el análisis de sistemas las elabore y defina los estándares que se
emplearán.
2. Ámbito de la calidad del software: diseño

Según Chemuturi (2010), la calidad del diseño se refiere a qué tan bien el producto o
servicio es diseñado. El principal objetivo es cumplir las especificaciones definidas para el
producto o servicio (Sommerville, 2010). De igual manera que con la calidad de la

especificación, si se tiene un diseño de mala calidad, el resultado final no será el óptimo,

incluso si las especificaciones fueron definidas correctamente. Este ámbito se integra en
la fase de diseño de desarrollo de software.
Diseño conceptual Arquitectura del software,

Selecciona el enfoque Ámbitos de
navegación, flexibilidad,
a la solución entre la calidad
portabilidad,
del diseño
muchas alternativas mantenimiento
posibles
Fases
del diseño
Ingeniería Diseño de bases de

Ámbitos de
Trabaja en los detalles datos, especificaciones
la calidad
que generan la solución del programa, diseño de
del diseño
interfaces, reportes
Ámbitos de la calidad del diseño. Basado en Somerville, 2010.
Al igual que con las especificaciones, los ámbitos de calidad del diseño tienen una
relación directa con el ciclo de vida tradicional del software, pues se llevan a cabo en la
fase de diseño.
En este ámbito, una lluvia de ideas del equipo de desarrollo es muy útil para ayudar a los
diseñadores a llegar a la mejor solución para el proyecto.
3. Ámbito de la calidad del software: desarrollo

Usualmente, la fase de pruebas de un producto de software puede tomar más tiempo y
esfuerzos que el propio desarrollo en sí. Por esta razón, es aceptable que no se lleven a
cabo pruebas sobre el 100% del producto de software, siempre que la manera en la que
se desarrolle sea cuidadosa.
Las actividades que normalmente se llevan en la fase de desarrollo del ciclo de vida del
software comprenden:
 Creación de la base de datos y estructura de tablas
 Desarrollo de librerías
 Desarrollo de pantallas
 Desarrollo de reportes
 Desarrollo de planes de pruebas unitarias
 Desarrollo de procesos

En esta fase, la calidad se consigue si el código desarrollado se apega a las buenas

prácticas o guías del lenguaje de programación que se está empleando, por ejemplo, el
lenguaje de programación JAVA tiene en su sitio web un documento llamado Code
Conventions, que se refiere a las buenas prácticas y recomendaciones para el desarrollo
de sistemas de software bajo este lenguaje.
Las ventajas que se obtienen cuando se desarrolla a partir de este tipo de directrices son
muy importantes para garantizar el desarrollo de un sistema de software de calidad, así
como su futuro mantenimiento.
Entre dichas ventajas es posible considerar:
 Ahorro de tiempo de programación. Si el programador sabe exactamente cómo

nombrar y almacenar las variables, clases, funciones, librerías, etcétera, podrá ahorrar
mucho tiempo en su desarrollo.
 Optimización del desarrollo en equipo. Si en un mismo proyecto intervienen
diferentes desarrolladores, podrán darle seguimiento a códigos que no escribieron
inicialmente, ubicar y comprender rápidamente la lógica de la programación que ha
dejado su compañero(a).
 Disminución de errores. Si el código es fácil de leer y sigue las mismas directrices
de formato y asignación de nombres, los errores serán más fáciles de identificar desde
la misma fase de desarrollo.
4. Ámbito de la calidad del software: conformidad

Se relaciona con las fases de pruebas y mantenimiento del ciclo de vida del desarrollo de
software. En esta fase se evalúan los resultados obtenidos por el desarrollo final, y si se
cubren eficientemente los requerimientos de la fase de análisis. Se refiere a la
examinación de qué tan bien se lleva a cabo la implementación, de acuerdo con el diseño
y en el grado en que el componente de software desarrollado cubre los requerimientos.
Este concepto hace referencia a la forma en la que una organización asegura que un
producto fue desarrollado con calidad en las tres dimensiones antes mencionadas,
especificación, diseño y desarrollo.
Para efectuar una medición sobre los niveles de calidad logrados, se pueden seguir las
siguientes alternativas:
a) Emplear métricas de calidad que incluyan la eficiencia de los defectos removidos

de cada proceso a ser evaluado, métricas para la calidad de un producto y
densidad de defectos.
b) Comparar los datos de las métricas de calidad de la industria con las que ha
generado la organización.

Este tema abarcó la relación que existe entre el ciclo de vida del software y cómo es
posible analizar si se están llevando a cabo controles de calidad en cada una de sus
fases. Es muy importante comprender cuáles son los ámbitos que definen la calidad del
software, debido a que en el siguiente tema se abordará la forma en que ésta se asegura,
a través de sus ámbitos de análisis: especificación, diseño, desarrollo y conformidad.
Actividad 1. Objetivos del aseguramiento de la calidad del software
Realiza la actividad de aprendizaje siguiendo las instrucciones y las indicaciones de tu

Docente en línea.
1.2. Aseguramiento de la calidad del software
En el tema anterior se revisó el concepto de la calidad del software desde un punto de

vista más administrativo, desde la presentación de los estándares internacionales hasta
los ámbitos que analizan la calidad y nivel de ciclo de vida del desarrollo de software.
En este nuevo tema, el objetivo fundamental será implementar aquellos mecanismos que
permitan tener la certeza de que los esfuerzos realizados en busca de la calidad no sean
desperdiciados, implementando controles sobre los procesos y resultados para que en
determinado momento puedan ser detectados errores (pruebas) no vistos durante el
desarrollo, o simplemente para adaptar el software a nuevos requerimientos del usuario
(mantenimiento). En este momento es posible ver que, en la búsqueda de la máxima
calidad en el desarrollo de software, son de vital importancia las fases de pruebas y
mantenimiento, sea cual sea el modelo elegido para el ciclo de vida o el estándar bajo el
que se lleven a cabo los desarrollos.
Aseguramiento de la calidad de las especificaciones

“Si algo empieza bien, terminará bien”, dice el dicho popular. Esta misma idea es el
fundamento de que el aseguramiento de la calidad del software comience desde las
raíces del producto: las especificaciones.
En tu experiencia profesional o académica, seguramente te has encontrado ante

problemas que te han hecho pensar: “este error se pudo haber evitado si se hubiera
definido bien el requerimiento”. Y sí, muchos retrasos en el desarrollo de software son
debido a que, desde un principio, los alcances no son definidos o analizados
correctamente. Las deficiencias que esto provoca se arrastran durante todo el desarrollo,
haciendo más grande el problema entre mayor avance exista en el proyecto.

De acuerdo con Llorens (2005), la IEEE define al aseguramiento de la calidad del

software como un patrón planeado y sistemático de todas de las acciones necesarias,
para proveer suficiente confianza de que el software se construye conforme a las
especificaciones técnicas preestablecidas.
Como se mencionó anteriormente, en el subtema 1.1.3. Ciclo de vida del software y

ámbitos de análisis de la calidad, el planteamiento de las especificaciones es el primer
paso para la construcción de cualquier producto o servicio. En el desarrollo de software,
las especificaciones son más conocidas como requerimientos del usuario (Sommerville,
2011). Los siguientes son algunos escenarios para la obtención de requerimientos:
1. Estudio de factibilidad que conduce el analista de software. Se escribe un reporte e

integra los requerimientos del usuario. Algunas de las actividades del analista
comprenden:
 Organizar reuniones con todos los usuarios finales, con todos los directivos y
gerentes involucrados en el proceso. En estas reuniones se recaban requerimientos
y preocupaciones sobre el desarrollo.
 Reunir la información obtenida y presentarla tanto a usuarios finales como a directivos
y gerentes para su validación; en su caso, recibir retroalimentación con modificaciones
en los requerimientos.
 Implementar las modificaciones obtenidas en la retroalimentación y concluir las
especificaciones.
2. Se realiza una solicitud de desarrollo donde se integra un conjunto de requerimientos

de usuario.
3. Se realiza una solicitud que toma como base un producto de software similar al
deseado, y se incluye la personalización que se requiere para adaptarlo a los
requerimientos del usuario.
Sin importar cuál sea el escenario desde el que fueron generadas las especificaciones, y
una vez que están definidas, el aseguramiento de la calidad del software comienza su
intervención, organizando, clasificando y evaluando las especificaciones obtenidas.
De acuerdo con Chemuturi (2010), la función principal del aseguramiento de la calidad de

esta etapa del desarrollo de sistemas de software es certificar que los requerimientos de
usuario (especificaciones) han sido recabados de manera exhaustiva y cubren las
siguientes áreas:
 Funcionalidad
 Capacidad
 Confiabilidad
 Seguridad

 Uso, entre otras
El objetivo del aseguramiento de la calidad, en el ámbito de las especificaciones, es que

los analistas de sistemas puedan desarrollar requerimientos que sean comprensibles,
claros y puntuales, sin ambigüedades, ya que estas características serán el marco de
calidad del siguiente ámbito que es el diseño. Para lograr dicho objetivo, los analistas
pueden ayudarse de las siguientes herramientas:
Documentación de procesos. Detalla la metodología mediante la cual se van a reunir,

desarrollar, analizar y redactar las especificaciones.
Estándares y lineamientos. Detallan las especificaciones mínimas que deberán ser

obtenidas en este proceso.
Listas de comprobación. Ayuda a los analistas a asegurar que la amplitud de las

especificaciones cubrirá los alcances del proyecto.
Aseguramiento de la calidad del diseño
El proceso de diseño puede ser explicado de manera muy simple de la siguiente forma:
Producto
final
Especificaciones: Diseño: conceptual y Desarrollo:

requerimientos del de ingeniería código fuente
usuario
Flujo de procesos del desarrollo de software. Basado en Sommerville, 2011.
En la gráfica anterior es posible observar cómo, en la fase de diseño, se convierten las
especificaciones en un documento que indica a los programadores qué componentes de
software deben programar para llegar al producto final.
De igual manera que en el proceso anterior (aseguramiento de la calidad en las

especificaciones), y de acuerdo con Chemuturi (2010), los diseñadores cuentan con las
siguientes herramientas que les ayudan a llevar a cabo el aseguramiento de la calidad en
el diseño:
Documentación de procesos. Detalla la metodología en la que se van a diseñar las

diferentes alternativas de diseño, así como los criterios de cómo se va a seleccionar una

de esas alternativas para el proyecto, hasta finalizar con el diseño conceptual que se
refiere a determinar cómo se va a almacenar, manipular y distribuir la información.
Estándares y lineamientos. Se especifica una posible arquitectura para el desarrollo del

software. Incluye las ventajas y desventajas que conlleve, así como la metodología para
tomar caminos alternativos en el diseño.
Listas de comprobación. Ayuda a los diseñadores a asegurar que el diseño se lleve a

cabo integralmente y de manera apropiada.
Aseguramiento de la calidad del desarrollo
En esta etapa del ciclo de vida de sistemas, es posible pensar que si se han llevado a
cabo de manera correcta las dos fases anteriores (especificaciones y diseño), tendrá
como consecuencia que la fase del desarrollo sea correcta también.
Sin embargo, esta fase puede tener muchos defectos de calidad, debido a que la forma
de desarrollar el código va a depender propiamente del programador que lo haga; puede
que su resultado final cumpla lo establecido en la fase de diseño, pero que el componente
de software que desarrolle consuma muchos recursos del sistema o que su código sea
ilegible para otros desarrolladores, provocando así un mantenimiento más costoso.
Para integrar y asegurar la calidad de esta fase, únicamente es necesario establecer

claramente las pautas o directrices que se deberán llevar durante la elaboración del todo
el código fuente que comprende el desarrollo. Éstas incluyen:
 Los estándares propios de la organización para escribir código de calidad. Pueden

abarcar la forma en la que serán nombrados elementos importantes del sistema de
software como variables, nombres de carpetas, funciones, clases, etcétera.
 Lineamientos que definen la forma en que se deberán llevar a cabo los cambios en el
código, pues si se realizan cambios de manera incontrolada, pueden provocar
problemas en la calidad del código. Partiendo de estos lineamientos, es posible hablar
de dos procesos importantes: administración de cambios y administración de
configuraciones que se encargarán de dar un seguimiento a dichas modificaciones,
pero sin crear estragos en el resto del proyecto.
Finalmente, para asegurar que la fase de desarrollo fue cumplida bajo un esquema de
calidad, se puede aplicar un proceso que ayuda a garantizar este hecho: pruebas de
sistemas de software, mismo que se detallará en la unidad 2 de esta asignatura.

Aseguramiento de la calidad de la conformidad
Llorens (2005) señala que G. J. Myers1, estableció que la confiabilidad del software es la
probabilidad de que se ejecute con éxito y sin fallas por un determinado tiempo,
ponderada por el costo que representa para el usuario cada falla.
El asegurarse de que un producto de software cumple con la calidad de la conformidad,

se realiza mediante la aplicación y análisis del resultado de las métricas internas de la
calidad, para ello se toman elementos tales como:
a) Funcionabilidad
b) Fiabilidad
c) Usabilidad
d) Entendibilidad
e) Eficiencia
f) Mantenibilidad
g) Transportabilidad
Las métricas son aplicadas a un producto de software no ejecutable y durante las etapas
de su desarrollo. Permiten medir la calidad de los entregables intermedios, predecir la
calidad del producto final, y hacer posible que el usuario inicie acciones correctivas
tempranas en el ciclo de desarrollo.
Lo anterior da lugar a:
 La eficiencia en la eliminación de defectos de las actividades de verificación y

validación
 La detección oportuna de defectos descubiertos y reportados en una determinada
etapa del desarrollo
 La medición de la densidad de defectos
La calidad de la conformidad se construye a través de la definición de procesos, de la

mejora continua de todas las actividades implicadas en el desarrollo de sistemas de
software, y del aseguramiento de la calidad.
1
Científico norteamericano de la computación moderna.

1.2.1. Estándares para el aseguramiento de la calidad del software
En el desarrollo de software es muy común hablar de paradigmas, de modelos, de

metodologías, de cómo se deben hacer las cosas. En principio, esta idea no es mala,
pues si ya se tienen las instrucciones exactas y precisas de cómo hacer una labor, se
podría pensar que no hay espacio para equivocaciones y que, siguiendo la receta de
cocina, el platillo quedará perfecto.
¿Y qué pasa si esa metodología o paradigma no es la mejor solución? ¿Valdrá el

esfuerzo de realizar un trabajo siguiendo métricas exactas pero incorrectas?
Estas interrogantes son las causantes de que hoy en día la tecnología se encuentre en un
nivel de crecimiento muy acelerado, y que se cuenten con más y mejores servicios de
tecnologías de la información. Los más grandes visionarios de este mundo han sido
aquellos que se han cuestionado los lineamientos con los que se deben de realizar las
cosas, y a partir de ello han llegado a nuevas y mejores maneras de realizarlas.
Esta reflexión inicial es pertinente, debido a que el cuestionar la manera en que se lleva a
cabo un proceso es parte fundamental del concepto de calidad. Por ejemplo, en un inicio,
la documentación de los sistemas no existía o se resumía a notas de los desarrolladores
sobre sus códigos, que solo ellos comprendían o podían interpretar. Posteriormente, los
equipos de desarrollo se dieron cuenta de que esta forma de trabajar no era eficiente y
cuestionaron sus procesos pues, cuando se necesitaba realizar mantenimiento a los
códigos, se convertía en una labor muy tediosa porque a los desarrolladores les costaba
mucho trabajo retomar lo previamente programado.
De acuerdo con Moliner (2005), el aseguramiento de la calidad es el conjunto de

actividades que tienen como objetivo proporcionar confianza en que se desarrollará un
software de calidad. A pesar de que las tecnologías de la información son una industria
relativamente joven, existen ya numerosos estándares que definen claramente las
actividades que deben aplicarse en el aseguramiento de la calidad.
Esta problemática se resuelve creando estándares que han mejorado la forma en que se
hacen los procesos. Ellos mismos han evolucionado de acuerdo con las necesidades de
los usuarios.
Estándar IEEE 730-2002 para Planes de Aseguramiento de la Calidad del Software

(SQAP)
La IEEE aporta su estándar 730-2002 que evalúa los planes de aseguramiento de la
calidad del software. Para Galin (2004), esta norma contempla los lineamientos para el
proceso de planificación de proyectos, y así asegurar la calidad del software.

La relación que guarda este estándar con las pruebas y mantenimiento de software,
consiste en que describe los procesos como un plan integral que debe elaborarse
sistemáticamente para su correcta ejecución.
El objetivo de elaborar planes de pruebas y mantenimiento es reforzar las actividades del

aseguramiento de la calidad, identificando previamente las estrategias que se llevarán a
cabo durante el proyecto; además de que se definen sus objetivos.
De acuerdo con este estándar, los planes para el aseguramiento de la calidad del
software contemplan los siguientes elementos (Galin, 2004):
 Propósito: objetivo específico que tendrá el plan de SQA. El propósito de un plan de
SQA es delimitar claramente su alcance, enlistando los componentes de software y su
uso.
 Documentos de referencia: lista completa de todos los documentos a los que se

hace mención en el plan de SQA, entre estos se pueden encontrar los relativos a la
documentación propia del software, tales como diagramas de clases o casos de uso,
diagramas relacionales de la base de datos, reportes generados por el sistema o de
manera manual, entre otros.
 Administración: la forma en la que se va a administrar el equipo de trabajo que lleve

a cabo el plan de SQA. Se menciona quiénes son los integrantes del equipo, sus roles
en el proyecto, las tareas que se van a llevar a cabo, así como una estimación de los
recursos que se requieren para la ejecución del proyecto.
 Documentación: elementos que se va a generar a partir de la ejecución del plan de
SQA. Comprende, como mínimo, la descripción de requisitos y diseño del software,
planes de gestión, verificación y validación del software, así como reportes de
resultados sobre la ejecución del plan.
 Estándares y convenciones: contempla la referencia de los estándares que se van a

implementar en el desarrollo. Si el equipo cuenta con convencionalismos particulares,
estos también deberán incluirse.
 Revisiones y auditorias: deberán llevarse a cabo como parte del plan SQA. Entre las
más importantes se encuentran las revisiones de las especificaciones, del diseño y de
la implementación del software. Entre las auditorías más importantes se destacan la
de funcionalidad, de fechas de entrega y de diseño.
 Reporte de problemas y acciones correctivas: este es uno de los rubros más

importantes, pues contempla las acciones que deberán llevarse a cabo ante la
presencia de algún error. Incluye la manera en la que se va a reportar y dará

seguimiento, así como el plan de acción para resolverlo. Incluye tanto los productos de
software como el propio proceso.
 Herramientas, técnicas y metodologías: Contempla los elementos con los que el

plan SQA se debe llevar a cabo; por ejemplo, el software que se emplee durante el
seguimiento del plan.
 Control de código: la forma en la que deberá escribirse el código fuente del producto
de software. Incluye control de versiones, librerías, clases y convencionalismos
particulares, tales como la forma en la que se nombran las variables o las clases.
 Control de medios: contempla la infraestructura de tecnología donde el producto de

software reside, así como los procedimientos para su resguardo y generación de
respaldos.
 Control de proveedores: es el establecimiento de las estrategias que deberán

llevarse a cabo para garantizar que el software proporcionado por proveedores
externos sea de calidad, y cumpla con los requerimientos por los cuales fue adquirido.
Este rubro también aplica, al equipo de cómputo adquirido.
Estándar ISO 9001:2008–Sistemas de gestión de la calidad
De acuerdo con Vértice (2010), el estándar ISO 9001:2008 establece los lineamientos
necesarios para implementar sistemas de gestión de calidad. Según estadísticas
mostradas en el sitio web del organismo, es empleado por más de un millón de empresas
y organizaciones en más de 170 países.
Seguir estándares no es contar con una varita mágica que solucione todos los problemas
de una empresa, multiplique exponencialmente las utilidades, y elimine al máximo los
costos. Contar con un estándar como este implica todo un proceso que debe, en primer
lugar, cumplirse y posteriormente medirse o evaluarse.
Un sistema de gestión de la calidad asegura y demuestra la calidad de los productos o

servicios que ofrece una organización.
Este estándar abarca a las organizaciones en un nivel general, va más allá del equipo de
desarrollo de software para integrar a todas y cada una de las áreas que componen su
estructura. Esta integración representa, para toda la organización, numerosas ventajas de
operación. La principal es que se definen y documentan claramente los procesos de la
organización.

Este material es de suma importancia para los analistas de sistemas, pues cuentan con
una herramienta muy poderosa de análisis que les permitirá realizar mejor su trabajo al
proponer o diseñar sistemas que optimicen dichos procesos.
Esta misma perspectiva de rayos-x del negocio permitirá elaborar proyectos de pruebas y
mantenimiento de software más eficientes, debido a que se contará con la información
suficiente para planear los procesos sin afectar la operación de la organización.
Sobre los estándares ISO de pruebas de software, se pueden mencionar los

ISO/IEC/IEEE 29119, conjunto de normas para las pruebas de software que se pueden
utilizar en el ciclo de vida de desarrollo. Mediante la implementación de estas normas, la
organización obtiene un enfoque de alta calidad por ser reconocidas a nivel internacional.
El estándar ISO ISO/IEC/IEEE 29119 se conforma de cinco normas que se explican a
continuación (ISO/IEC/IEEE 29119 Software Testing, 2013):
ISO/IEC 29119-1: conceptos y definiciones (publicado en septiembre de 2013), este

apartado es informativo y proporciona definiciones, una descripción de los conceptos de
pruebas de software y la forma de aplicar los procesos, documentos y técnicas definidas
en la serie 29119.
ISO/IEC 29119-2: pruebas de procesos (publicado en septiembre de 2013), define un

modelo de proceso genérico para las pruebas de software, que se puede utilizar dentro de
cualquier ciclo de vida del desarrollo de software.
ISO/IEC 29119-3: pruebas de documentación (publicado en septiembre de 2013),

define plantillas para la documentación de prueba que cubre todo el ciclo de vida de
pruebas de software.
ISO/IEC 29119-4: técnicas de prueba, define un estándar internacional que cubre las
técnicas de diseño de pruebas de software (también conocidas como técnicas de diseño
de casos de prueba o métodos de prueba), que se puede utilizar durante el diseño de
prueba e implementación de procesos, dentro de cualquier organización o del ciclo de
vida de del desarrollo de software.
ISO/IEC 29119-5: prueba de manejo de palabras clave, define un estándar

internacional para apoyar las pruebas, describe los elementos utilizando un conjunto
predefinido de palabras clave, las cuales se refieren a nombres asociados con un
conjunto de acciones requeridas para realizar un paso específico en un caso de prueba.
Mediante el uso de palabras clave para describir los pasos de prueba en lugar del
lenguaje coloquial, se facilita entender, mantener y automatizarlos.

Además, sobre la base de los procesos definidos en la norma ISO/IEC/IEEE 29119-2, el

estándar ISO/IEC 33063: evaluación modelo de proceso, permite:
 La descripción del objetivo y el resultado del proceso, que está soportado por un
conjunto de indicadores de desempeño de los procesos.
 Los niveles de capacidad y atributos de proceso definidas en la norma ISO/IEC 33020
(evaluación del proceso-marco de medición para la evaluación de la capacidad del
proceso y la madurez de la organización), y su escala de calificación asociada.
Los sistemas de gestión de calidad tienen la filosofía de la mejora continua y cumplimiento

de objetivos; por lo tanto, su naturaleza dará prioridad al seguimiento de proyectos de
pruebas y mantenimiento de software cuando se detecte que, en este ámbito de la
organización, los objetivos no se están cubriendo de la manera en la que se han definido
previamente.
Actividad 2. Estándares del aseguramiento de la calidad del software
Realiza la actividad siguiendo las instrucciones y las indicaciones de tu Docente en

línea.
1.2.2. SQA (software quality assurance)
El SQA, aseguramiento de la calidad del software (software quality assurance, por sus
siglas en inglés), es un esfuerzo más por estandarizar los procesos y modelos que
evalúan y aseguran un sistema de software con un nivel alto de calidad.
Es posible definir al SQA como un conjunto de actividades que tienen como objetivo
proporcionar confianza en que se desarrollará un software de calidad. Las actividades del
SQA abarcan todo el proceso de desarrollo de software. El aseguramiento de la calidad
del software asegura que el producto cumple con los requisitos técnicos del sistema
(Moliner, 2005).
Llorens (2005) señala que el término inglés software quality assurance (SQA) se traduce
comúnmente como control de calidad en sistemas, y que una unidad SQA en una
organización tiene como función principal motivar, promover y controlar la calidad de los
sistemas. Según Llorens, en la década de los años 80, ante el éxito de la industria
japonesa, las empresas prestaron mayor atención a la calidad de sus productos y
servicios con base en la experiencia japonesa, la cual se centró en:

 Definir estándares de calidad en cuanto al producto

 Definir estándares de calidad dirigidos a los métodos utilizados para obtenerlos, es
decir, en cuanto a la calidad del proceso
 Establecimiento de los mecanismos necesarios para asegurar que se obtiene el nivel
de calidad deseado, es decir, para un control de calidad
 Cuestionamiento permanente de los métodos, los procesos y los productos para
continuar hacia niveles de calidad superiores
El SQA se ubica como parte de la organización del área de informática, su función es

“motorizar este proceso de florecimiento continuo de la calidad. Para ello, echa mano de
la metodología, ya que ésta le permite establecer métodos -calidad del proceso-
estándares- calidad del producto sobre los cuales se puede definir y evaluar la calidad de
un sistema de información” (Llorens, 2005, p. 137).
Los sistemas de calidad, tanto su generación como el mantenerlos, no es responsabilidad

únicamente de SQA, sino que involucra a todos los que están relacionados con el sistema
de software o de información, tales como gerentes, analistas, programadores, usuarios,
etcétera.
El aseguramiento de la calidad del software se relaciona de manera muy directa con los
procesos de pruebas y mantenimiento de la siguiente forma: entre mayor sea el grado de
calidad de un producto de software, éste tendrá menos errores; mientras que si el
producto de software no es desarrollado bajo ningún esquema de calidad, los errores
serán numerosos y requerirá mayor esfuerzo en las fases de pruebas y mantenimiento.
Las funciones generales del SQA son (Rojas,Borja, 1999):

 Soporte a la metodología
 Definición de guías y estándares
 Evaluación y selección de herramientas
 Desarrollo de un ambiente de calidad y productividad
 Vigilar el proceso de desarrollo de software con el fin de asegurar que el proceso
establecido se está realizando tal como se planeó, para ello, realiza diversas acciones
tales como:
 Verificar los productos para identificar posibles deficiencias. Establecer que se
cumpla el plan de desarrollo del proyecto y el proceso de desarrollo de software
 Valorar el proceso y no el producto
 Desde la posición del cliente, el trabajo del equipo de SQA lo representa. Entre las
funciones en este papel se identifican:
 Señalar la funcionalidad que el cliente desea

 Apoyar en el proceso de sensibilización de la organización para con sus

requerimientos.
 Actuar como un cliente de prueba para obtener la más alta satisfacción
 En el papel de analista, la acción de recabar información es un trabajo del equipo de

SQA. Entre las funciones en este papel son:
 Conjuntar los datos sobre todos los aspectos del producto y del proceso
 Con la base de información recabada, mejorar los procesos y los productos
 Como entidad suministradora de información, el trabajo del equipo de SQA se

centra en observar:
 Lo que ya está hecho para identificar áreas de mejora
 Los objetivos técnicos que se están cumpliendo para apoyar las decisiones de la
alta gerencia
 Suministrar información técnica objetiva
 Suministrar la información correcta de las clases de productos y sus riesgos
 Identificar e implementar estrategias para la reducción de los riesgos
 Como responsable de los procesos, el equipo de SQA, en su totalidad, participa en

la definición de los planes, procesos, estándares y procedimientos para asegurar que
se ajustan a las necesidades del proyecto, incluyendo la estrategia de evaluación de
QA (quality assurance), acorde con los requerimientos y las políticas de la
organización. Es recomendable comenzar desde las fases iniciales del proyecto para
cumplir con el rol de aseguramiento de la calidad.
Es posible que el equipo que define la metodología no pertenezca al equipo de QA, y sea
el SEPG (software engineering process group), equipo totalmente independiente
encargado de definir la metodología, mientras que el equipo de QA se limita a verificar
que se cumpla.
La importancia de implementar SQA en el desarrollo de software, puede apreciarse mejor

en la siguiente gráfica:

COSTOS
ADCPIO
Costo de corregir defectos en cada fase del ciclo de vida de software. Tomado de Reynolds, 1995.
Como es posible apreciar, conforme avanza el desarrollo del proyecto, el costo por
corregir defectos se incrementa notoriamente. Nótese que en la fase de análisis este
costo es casi nulo. Una ventaja de implementar SQA en los proyectos de desarrollo de
software, es que si la fase de análisis ha sido controlada bajo el esquema de calidad, los
errores que se presenten en su fase de operación serán mínimos o nulos, reduciendo de
esta manera los costos por mantenimiento.
Según Moliner (2005), entre las principales actividades que se llevan a cabo en el SQA se
encuentran:
 Seguimiento al proceso de desarrollo: evalúa que el progreso del proyecto sea de

acuerdo con los estándares para el desarrollo de software que se hayan definido.
 Revisiones: evalúan la calidad de los productos desarrollados y los avances de cada

fase del ciclo de vida del software. Este paso se encarga de detectar errores
oportunamente.
 Análisis de errores: se analiza el origen de los errores que son detectados con el
objetivo de definir estrategias que ayuden a prevenirlos y corregirlos.
 Configuraciones: se vigila la integridad de los componentes del software durante

todo su ciclo de vida. En este rubro es indispensable contar con medios para el control

de cambios, y así contar con el registro de las modificaciones que llegarán a tener
dichos componentes.
 Pruebas: miden el nivel en el que el producto de software cubre satisfactoriamente los

requerimientos. Esto se logra definiendo objetivos de calidad y comparándolos con los
resultados de operar el software.
De acuerdo con Galin (2004), los siguientes son algunos elementos que comprende un
plan de SQA:
1. Objetivos de calidad
Hace referencia a los lineamientos de calidad del sistema desarrollado. En otras palabras,
se refiere a la funcionalidad que se espera tenga el software.
Los objetivos de calidad sirven como métricas para el éxito con el que el software cumple
los requerimientos del cliente.
2. Plan de actividades de revisión

Debe presentar una relación completa de todas las actividades de revisión contempladas
en el plan. Incluye inspecciones al diseño y al código.
Por cada actividad de este plan se deben describir los siguientes puntos:
 Tipo de actividad
 Alcance
 Planificación
 Procedimientos
 Personal que ejecutará la actividad
3. Plan de pruebas del software

SQA debe presentar una relación completa de todas las pruebas de software planificadas.
Por cada actividad de este plan se deben describir los siguientes puntos:
 El elemento del desarrollo que se va a probar (programa, módulo, sistema

completo)
 Tipo de prueba
 Planificación
 Procedimientos
 Personal que ejecutará la actividad

En la siguiente unidad se abordarán a detalle las técnicas de pruebas más empleadas en

el desarrollo de software.
4. Plan de pruebas de aceptación para software desarrollado externamente

Es muy importante tener presente que el software no siempre es desarrollado en su
totalidad por el equipo interno de una organización, también es posible encontrar
situaciones en las que se contrata a desarrolladores externos para realizar los productos.
Que el software sea realizado por terceros no significa que no sea susceptible de entrar
en el plan SQA. En estos casos, lo más recomendable es que el personal experto en
tecnología participe directamente en la elaboración de los requerimientos que deberá
cumplir el software externo, junto con el personal de las áreas que hicieron la solicitud de
la adquisición.
En el plan SQA se debe contar con una relación completa del software desarrollado
externamente. Los puntos que deben incluirse son:
 Software adquirido
 Software desarrollado por terceros
 Software proporcionado por el cliente
5. Gestión de la configuración
El plan SQA debe especificar los procedimientos para la gestión de configuración,
incluyendo un control de cambios que se aplica a todo el proyecto.
Los procesos del SQA contemplan a todas las actividades involucradas en el ciclo de vida
de sistemas de software: análisis, diseño, desarrollo, implementación, pruebas y
mantenimiento (Sommerville, 2011). Es importante analizar la forma en que estos
procesos son llevados a cabo dentro de las organizaciones, así como los miembros del
equipo de desarrollo que los llevan a cabo. Estas recomendaciones se analizan en el
siguiente apartado.
SQA en las organizaciones

Típicamente, el departamento de sistemas o tecnologías de la información de una
organización tiene a su cargo todo lo relacionado con los procesos tecnológicos que se
requieren, tales como la infraestructura de telecomunicaciones, la adquisición de equipos,
el diseño y operación de sistemas, el sitio web, la Intranet, etcétera. Pero muy
comúnmente queda de lado un área específica que se dedique a evaluar y vigilar el
cumplimiento de los estándares de calidad de los sistemas de software.

La principal razón de esta ausencia organizacional se fundamenta en los costos que un

departamento propio de calidad conlleva, así que dichas actividades son delegadas al
propio personal de desarrollo de software. El resultado de esta forma de trabajo es que
los asuntos relacionados con el control de calidad son superados por las labores de
desarrollo o mantenimiento, quedando así descuidado el enfoque de integrar la calidad a
los sistemas de software que se desarrollen.
Las ventajas de que exista, dentro del equipo de trabajo, un rol dedicado por completo al
aseguramiento de la calidad, conllevan múltiples mejoras que justifican por completo los
costos que se generen. Por ejemplo, analiza los siguientes escenarios:
Equipo de desarrollo sin personal Equipo de desarrollo con personal

propio de SQA propio de SQA
Se realizó la implementación de un Se realizó la implementación de un

sistema que no tuvo supervisión de sistema que tuvo, desde sus fases
calidad. En plena producción, los usuarios iniciales, participación del equipo de SQA.
han comenzado a detectar errores en el En plena producción, los usuarios han
sistema, por lo que han tenido que detener notado que cubre muy bien los
los procesos por completo y realizarlos de requerimientos por los que fue solicitado,
manera manual, lo que conlleva menos incluso con un nivel superior de lo
productividad para la organización y esperado. La organización redujo costos
aumento de costos de operación. de operación e incremento su
productividad.
El equipo de desarrollo se encuentra

trabajando de lleno en corregir los errores El equipo de desarrollo se encuentra
del sistema, descuida los proyectos en trabajando en nuevos proyectos.
desarrollo y provoca un desfase de los
tiempos de entrega.
Diferencias entre la participación y la ausencia de un equipo de SQA. Basado en Moliner, 2005.
El escenario anterior puede parecer fatalista o exagerado, pero no es muy distante de la

realidad de muchas organizaciones: sistemas que se implementan sin un control de
calidad y sin haber pasado por suficientes pruebas para asegurar su óptimo
funcionamiento, o su respuesta ante fallos.
Una vez analizado lo anterior, los costos que pudiera representar el contar con personal
dedicado al aseguramiento de la calidad, no son comparables con los costos que puede
llegar a generar el hecho de no tener a la calidad como eje de desarrollo de sistemas de
software.

A las personas que llevan a cabo las actividades del SQA se les conoce como analistas
de la calidad del software, y su principal función es la de vigilar el uso correcto de los
estándares de la organización como los que se estudiaron en el tema 1.1.1. Estándares
internacionales: ISO e IEEE, el estándar ISO/IEC 25000 y el IEEE 12207.
Es necesario hacer la aclaración de que el SQA no es el responsable de que un software

tenga calidad, su función principal es evaluar el proceso de desarrollo de sistemas de
software en sus diferentes fases, así como vigilar el seguimiento y cumplimiento de los
estándares.
Al finalizar esta unidad, es conveniente hacerse esta pregunta: ¿qué relación existe entre
el aseguramiento de la calidad del software, las pruebas y el mantenimiento de sistemas
de software? Supóngase dos proyectos de desarrollo de software, el primero es
desarrollado bajo el estándar ISO/IEC 25000 y auditado en SQA; mientras que el segundo
no es desarrollado bajo ninguna estandarización ni auditado en SQA.
¿En qué proyecto existirá una mayor necesidad de implementar proyectos de pruebas y
mantenimiento? ¿Serán igualmente confiables o tendrán la misma calidad? En definitiva,
el proyecto desarrollado bajo esquemas estandarizados y auditado en SQA tendrá menor
necesidad de pruebas y mantenimiento debido a que, durante todo su desarrollo, cada
fase tuvo a la calidad como punto de partida.
Autoevaluación
Realiza la autoevaluación con el fin de que puedas analizar el avance que has tenido, así
como detectar las áreas de oportunidad respecto al estudio de la primera unidad.
Evidencia de aprendizaje. Aseguramiento de la calidad del software
Realiza la Evidencia de aprendizaje con base en las instrucciones y las indicaciones

de tu Docente en línea.
Autorreflexiones
Elabora tus autorreflexiones con base en las indicaciones de tu Docente en línea.

Cierre de la unidad
Durante esta unidad has conocido un tema fundamental en el proceso de desarrollo de

sistemas de software, que es considerar el concepto de calidad como un elemento clave
de cada fase del desarrollo, con el fin de que los componentes que desarrolles cumplan
con éxito el objetivo por el que fueron creados.
Esta primera unidad también ha analizado los ámbitos que definen la calidad del software
en las distintas fases del ciclo de vida, las cuales son:
 Calidad de la especificación (fase de análisis)
 Calidad del diseño (fase de diseño)
 Calidad en el desarrollo (fase de implementación)
 Calidad de la conformidad (fase de mantenimiento)
De igual manera, se relacionaron cada una de estas fases con las actividades que se
deben seguir para asegurar que el desarrollo sea de calidad. En este sentido, es muy
importante recordar que no es necesario seguir un determinado modelo del ciclo de vida
para que pueda ser integrado al enfoque de calidad, pues los ámbitos de análisis de la
calidad funcionan de manera general, y se adaptan al modelo que se esté empleando
para el desarrollo. El siguiente paso en la búsqueda de la calidad y mejora continua, es el
análisis de fondo de cada uno de los procesos del desarrollo de software, con el objetivo
de optimizarlos mediante la detección y resolución de errores.
En esta unidad se analizaron también las diferentes connotaciones que tiene el concepto
de calidad, y cómo puede aplicarse en las organizaciones. Los estándares internaciones
son una excelente referencia para encaminar nuestro trabajo profesional por el camino de
la calidad. Recuerda que estos estándares deben adaptarse a nuestras necesidades, pero
es necesario revisar su vigencia, pues constantemente se actualizan y mejoran.
Estos temas te han proporcionado las bases necesarias para avanzar en las siguientes
unidades. Con lo visto, podrás orientar los proyectos de pruebas y de mantenimiento de
sistemas de software a la búsqueda de la mejora continua con un enfoque de calidad.
Recuerda que la mejor manera de aprender y comprender estos temas es practicar.

Vuelve a repasar la información que aquí se te presentó, practica la integración de la
calidad a tus proyectos de desarrollo de software académicos y laborales.

Para saber más
Code Conventions for the Java Programming Language

La calidad en la fase de desarrollo de software, depende en buena medida de la manera
en la que el código es escrito. Oracle ofrece, en su sitio web, el documento llamado Code
Conventions for the Java Programming Language, que contiene una serie de buenas
prácticas y lineamientos para el desarrollo de componentes de software que usen este
lenguaje. Este recurso se encuentra disponible en formato HTML o PDF, y es una
excelente guía para tener la referencia de la forma en que se recomienda escribir código
de un lenguaje de programación.
 http://www.oracle.com/technetwork/java/codeconv-138413.html
Norma ISO 9126

Existen en los portales de videos, numerosos clips que explican la familia de normas ISO
9126, puedes consultarlos para reforzar la comprensión de este tema.
Midiendo la calidad del software

Si deseas saber más acerca de cómo medir el nivel de la calidad del software, se te
sugiere leer el siguiente artículo que Francisco Valdés Souto escribió para la revista
Software Gurú (Mayo-Julio 2013).
 http://franciscovaldessouto.wordpress.com/2013/04/24/midiendo-la-calidad-de-
software-caso-practico-2/
Fuentes de consulta
 Calero, C., et ál. (2010). Calidad del producto y proceso software. España: Ra-Ma.
 Campderrich, B. (2013). Ingeniería del software, 5a. ed. España: UOC.
 Carrol, S., et ál. (2007). Fundamental Concepts for the Software Quality Engineer, 2a.
ed. Estados Unidos: American Society for Quality.
 Chemuturi, M. (2011). Mastering Software Quality Assurance: Best Practices, Tools

and Techniques, 3a. ed. Estados Unidos: J. Ross Publishing.

 Rojas, S.E., Borjas, J.J. (1999).Calidad del Software: camino hacia una verdadera
industria del software. Escuela de administración de negocios, 38, 42-44. Bogotá,
Colombia.
 Galin, D. (2004) Software Quality Assurance, from Theory to Implementation. Londres:

Pearson Education Limited.
 Goikoetxea, A. (2007). Enterprise Architectures and Digital Administration: Planning,

Design, and Assessment [Paperback]. Singapur: World Scientific Publishing.
 Grupo de trabajo AEN/CTN71/SC7/GT26. (2013). Pruebas de software. ISO/IEC/IEEE

29119 Software Testing Standard. Recuperado de http://in2test.lsi.uniovi.es/gt26/
 IEEE. (2008). 12207-2008-ISO/IEC/IEEE Standard for Systems and Software

Engineering-Software Life Cycle Processes. Recuperado de
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4475826&url=http%3A%2F%2Fi
eeexplore.ieee.org%2Fiel5%2F4475822%2F4475825%2F04475826.pdf%3Farnumber
%3D4475826
 ISO/IEC/IEEE 29119 Software Testing. (2013). The International Software Testing

Standard. Recuperado de http://softwaretestingstandard.org/index.php

 ISO 25000 Calidad del producto de software. (2014). La familia de normas ISO/IEC
25000. Recuperado de http://www.iso25000.com/index.php/normas-iso-25000
 Land, S., et ál. (2008). Practical Support for Lean Six Sigma Software Process
Definition: Using IEEE Software Engineering Standards. Estados Unidos: John Wiley &
Sons.
 Llorens, J. (2005) Gerencia de proyectos de tecnología de información. Venezuela:

CEC.
 Moliner, F. (2005). Informáticos generalitat valenciana. España: MAD.
 Reynolds, G. (1995). Information Systems for Managers, 3a. ed. Estados Unidos: West
Publishing Company.
 Sommerville, I. (2011). Ingeniería del software. 9a. ed. España: Pearson Educación.

 Tuya, J., et ál., (2007). Técnicas cuantitativas para la gestión en la ingeniería del
software. España: Netbiblo.
 Uddesh, K. (2007). Project Management Handbook. Nueva Delhi: McGraw-Hill.
 Vértice. (2010). Gestión de la calidad (ISO 9001/2008). España: Autor.

Unidad 1 Fundamentos Del Aseguramiento de La Calidad Del Software PDF

Cargado por

Copyright:

Formatos disponibles

Unidad 1 Fundamentos Del Aseguramiento de La Calidad Del Software PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 1 Fundamentos Del Aseguramiento de La Calidad Del Software PDF

Cargado por

Copyright:

Formatos disponibles

Pruebas y mantenimiento de sistemas de software

Unidad 1. Fundamentos del aseguramiento de la calidad del software

Ingeniería en Desarrollo de Software

Unidad 1. Fundamentos del aseguramiento de la calidad

Universidad Abierta y a Distancia de México

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 1

Unidad 1. Fundamentos del aseguramiento de la calidad del software .............................. 3

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 2

Unidad 1. Fundamentos del aseguramiento de la calidad del software

Un sistema de software, según Campderrich (2013):

Los fundamentos del aseguramiento de la calidad del software son un marco de

En el tema 1.1. Calidad del software en el entorno de las organizaciones, realizarás un

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 3

Al término de esta unidad lograrás:

1.1. Calidad del software en el entorno de las organizaciones

En la actualidad, todas las organizaciones requieren el apoyo de la tecnología para llevar

En esta primera unidad se expondrán los fundamentos de la calidad del software y la

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 4

 Para un productor de bienes, la calidad connota la conformidad con las

 Para un proveedor de servicios, la calidad connota proporcionar sus servicios en el

La importancia de la calidad del software va en aumento en cuanto al desarrollo de

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 5

1.1.1. Estándares internacionales: ISO e IEEE

En el ámbito de las pruebas y mantenimiento de sistemas de software, los estándares

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 6

Según se revisó en la asignatura Modelos de calidad de software, existen dos grandes

Norma ISO/IEC 25000:2005 Software product Quality Requirements and Evaluation

La familia de normas ISO/IEC 25000:2005 es una evolución de la ISO 9126.

El siguiente esquema representa la forma en la que se clasifican las diferentes categorías

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 7

Facilidad de ser analizado

Como complemento a la norma ISO/IEC 9126-1 existe la ISO/IEC 9126-2, que

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 8

ISO/IEC 9126-4 la calidad en el uso de las métricas para de la medición de las

Calero et ál. (2010) señalan que:

La evolución de familias de normas enfocadas en la calidad del software (especialmente

La familia de normas 9126 evolucionó para consolidarse en la 25000. Presenta, entre

 Mejor coordinación de la guía en la medición y evaluación de la calidad de los

1. ISO/IEC 2500n–División de Gestión de Calidad. Las normas ISO/IEC 2500n

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 9

2. ISO/IEC 2501n–División de Modelo de Calidad. Este apartado presenta modelos

3. ISO/IEC 2502n–División de Medición de Calidad. Incluye un modelo de referencia

4. ISO/IEC 2503n–División de Requisitos de Calidad. Ayudan a especificar los

5. ISO/IEC 2504n–División de Evaluación de Calidad. Incluye normas que

Si se desea implementar el estándar ISO/IEC 25000, es necesario contemplar los

1. Enfoque interno: ayuda a detectar deficiencias en el producto de software desde

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 10

El mantenimiento de software entra en juego como parte de las características internas de

Estándar IEEE 12207

El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) también cuenta con diferentes

El campo de aplicación de este estándar es muy amplio en los sistemas de software, y de

1. Procesos primarios. Se componen de las siguientes categorías:

 Adquisición. Procesos que realiza el cliente para la adquisición de un producto o

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 11

3. Procesos de la organización. Se componen de las siguientes categorías:

Las pruebas de software se encuentran presentes en los procesos primarios y de soporte

El mantenimiento de sistemas de software es parte también de esta norma, y se le puede

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 12

Procesos organizacionales del ciclo de vida