Unidad 4: Proceso de Control de Calidad de Producto

4.1 Calidad de Software para Productos

Actualmente, en el mercado de productos similares, la satisfacción hacia el uso de un producto
puede marcar una gran diferencia. La diferencia entre dos organizaciones que elaboran, fabrican o
comercializan productos que compiten en el mercado, está dada por los artículos que satisfacen
las expectativas de los clientes y usuarios.

En los últimos años se ha incrementado la preocupación por ofrecer productos acompañados de

altos niveles de calidad. A lo largo de este siglo han surgido distintas interpretaciones de como
brindar dicha calidad.

El desarrollo de productos software no es una excepción, ni está ausente de ofrecer calidad. Dicho
nivel de calidad, incluido en los productos, considera muchas actividades dentro del desarrollo de
los proyectos software. La gestión de la calidad dentro de este tipo de proyectos puede
estandarizarse dentro de la organización y certificarse a la comunidad de clientes.

La calidad del software ha mejorado en las últimas décadas, una de las razones ha sido que las
compañías han adoptado nuevas técnicas y tecnologías como el desarrollo orientado a objetos, la
ingeniería basada en componentes y las herramientas CASE.

Incorporar la calidad implica la adopción de técnicas y una gestión de la calidad para el desarrollo
en la industria del software, sin embargo, la calidad del software es un concepto complejo que no
es comparable con la calidad relacionada con la manufactura de los demás productos.

―En la manufacturación, la noción de calidad viene dada por la similitud entre el producto
desarrollado y su especificación‖. Philip Crosby, La calidad no cuesta, 1994. Esta definición es
aplicable a todos los productos, pero para el producto software no lo es, ya que existen
básicamente dos problemas:

1. En la manufactura de productos en general, la especificación se orienta hacia las

características del producto que el consumidor quiere. Además se tienen los
requerimientos de mantenimiento que no se incluyen en la especificación.
2. No se sabe cómo especificar ciertas características de calidad de una forma no ambigua,
por ejemplo, el mantenimiento.

En algunas organizaciones, las personas piensan que la calidad puede lograrse definiendo
estándares y procedimientos organizacionales de calidad que comprueban si estos estándares
son seguidos por el equipo de desarrollo, estos estándares marcan las buenas prácticas, lo que
lleva inevitablemente a un producto de alta calidad, pero en el software no se garantiza este
resultado, ya que es posible que el cliente considere que el producto final no cubre sus
expectativas.

Los buenos gestores aspiran a lograr una ―Cultura de calidad‖ dentro de la organización.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
-1-
4.1.1. Concepto de Calidad de Software para Productos
Concepto de Calidad

Antes de empezar hablar acerca de calidad de los productos software, es necesario definir que es
lo que se entiende por ―calidad”, a qué es aplicable y de qué forma puede ser relacionada con
productos software.

Según la Real Academia Española, calidad se puede definir como "Propiedad o conjunto de
propiedades inherentes a algo, que permiten juzgar su valor".

De esta forma podríamos decir que la calidad de los productos puede medirse como una
comparación de sus características y atributos. Este concepto puede aplicarse a cualquier
producto.

Esta medida de calidad debería hacerse observando las diferencias ocurridas en la producción de
dos productos iguales, pero la producción de artículos de cualquier especie no asegura que dos
de ellos sean totalmente iguales.

Es posible entonces, que sea preciso realizar observaciones acuciosas para lograr distinguir las
variaciones entre uno y otro, ya que éstas pueden no ser obvias. Es más, lo más seguro es que
sea necesario disponer de instrumentos adecuados y de precisión para poder observar dichos
cambios de la producción.

Eso marca uno de los principales objetivos de dar calidad a los productos, que es minimizar las
diferencias entre unidades producidas. Estas diferencias tienen diversos orígenes, lo que lleva a
tener distintas y amplias formas de corregirlos, dependiendo de la naturaleza del producto.

Lo importante y primordial es tener en cuenta el concepto de ―brindar calidad a lo que se está

realizando‖, siendo ésta una actividad esencial para un negocio que produce productos que serán
utilizados por otras personas.

Calidad en los productos Software.

Es posible detectar algunos de los atributos que hacen comparable un producto de otro, como
pueden ser las formas, colores, tamaños, manejabilidad, entre otros muchos. Estas características
pueden ser físicamente mensurables y, por ello, fácilmente comparables.
Desde esa perspectiva,
¿De qué manera puede ser aplicada la calidad a los productos software?
¿Cómo controlar la variación entre los productos de este tipo?

Así como existen medidas para atributos físicos de los productos, para el software también existen
medidas que pueden hacerlo comparable, tales como puntos de función, líneas de código y otras.

Estas medidas aportan a la medida de variación entre productos software, las métricas, pero no
queda claro contra qué medimos, ¿un valor mínimo?, ¿un valor máximo?

Así como los sistemas manufactureros producen o deben producir productos de calidad, podemos
pensar que la principal meta de un equipo desarrollador de software debería ser siempre producir
software catalogado como de alta calidad.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
-2-
Pero para ello se deben tener en cuenta lo siguiente:

 Los productos software son realizados por personas para personas.

 Las personas desarrolladoras deben tener en cuenta claramente que son otras personas
las que utilizarán sus productos, los que pueden estar sujetos a fallos constantes.

Los avances actuales en Inteligencia Artificial, con los asistentes para el desarrollo de software no
son demasiado confiables como para remplazar al ser humano en la intervención de este proceso.

Se confirma entonces que el desarrollo de productos software es una actividad sujeta a muchos
factores que pueden hacerla poco confiable.

Aunque muchas personas piensan que un producto de software de calidad empieza a

considerarse una vez que las primeras líneas de código son escritas, el concepto de calidad
involucra muchos factores previos a esta etapa, debiendo ponerse atención a cada una de ellas.
Este concepto es extensible a cualquier producto, ya que es importante considerar todo el ciclo del
proceso, partiendo por la definición de la idea del producto hasta la entrega y mantenimiento del
mismo.

La gestión de calidad del software se estructura en tres actividades principales:

 Garantía de la calidad, establecer un marco de trabajo de procedimientos y estándares
organizacionales que conduce a software de alta calidad.
 Planificación de la calidad, a partir del marco de trabajo, elegir los procedimientos y
estándares adecuados y adaptarlos al proyecto de software específico.
 Control de calidad, la debida definición y uso de los procesos que garanticen que los
procedimientos y estándares para la calidad son seguidos por el equipo de trabajo.
 Administración de la calidad, asegurando minimizar las diferencias entre los recursos
presupuestados y los recursos realmente utilizados en las distintas etapas.

Estas grandes actividades implican otras actividades tales como:

 Uso de tecnología de Ingeniería de Software eficiente, considerando métodos de desarrollo
y herramientas.
 Aplicación de técnicas formales a lo largo de todo el proceso.
 Minimización de las variaciones entre los productos, diminuyendo las diferencias y
defectos entre versiones.
 Control de la documentación, tanto de apoyo al desarrollo como la entregada al usuario
final, generada en cada etapa y verificación de los posibles cambios y modificaciones que
pudiera sufrir.
 Correcto mantenimiento y servicios de post-venta.

Calidad del proceso y por etapas

Podemos asegurar que la calidad del proceso de desarrollo afecta directamente a la calidad de los
productos derivados. Se mide la calidad del producto y se cambia el proceso hasta conseguir el
nivel de calidad deseado.

En forma general se puede representar de la siguiente manera.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
-3-
En el desarrollo de software la tarea de determinar la calidad del producto no es tan fácil, ya que
es difícil medir los atributos de la calidad del software, como lo es la mantenibilidad y sobre todo
que, casi siempre, es un producto para un cliente determinado con una variedad de usuarios a los
que debe satisfacer y cubrir sus expectativas. Otro factor importante son los cambios que sufren
los requerimientos durante el proceso de desarrollo.

La gestión y mejora de la calidad del proceso debe minimizar los defectos en el software
entregado.

Por lo tanto la calidad del proceso implica:

 Definir estándares de proceso.
 Supervisar el proceso de desarrollo, asegurando que siguen los estándares.
 Confeccionar los informes necesarios del proceso para el gestor del proyecto y para el
cliente.

Como la calidad está presente en todas las etapas del proceso de desarrollo de los productos de
software, se debe conocer cómo interviene la aplicación de la calidad en cada etapa. Teniendo en
cuenta que la etapa de captura de requerimiento necesita ser correcta para garantizar el éxito del
proyecto, quedan como etapas importantes, el diseño, la construcción y la satisfacción final del
cliente:
 Calidad en el diseño. Se definen las características de arquitectura e interfaz para la
realización del producto software y que se deberían cumplir posteriormente. Todas las
actividades están dentro de un proceso definido de acuerdo a alguna norma de calidad. Es
importante en esta etapa contemplar las especificaciones de los procesos, la propuesta de
tolerancia a la modificación estableciendo los métodos correctivos a las desviaciones que
puedan ocurrir.
 Calidad en la producción. El logro de la calidad está dado por el grado de cumplimento de
los requerimientos de diseño en la producción. Si los requerimientos están bien definidos y
especificados, el cumplimiento de la calidad en esta etapa no debería tornarse en una
tarea compleja ni estresante, ya que las bases del trabajo están previamente definidas.
 Calidad de satisfacción. La medida de la calidad está dada por los usuarios finales de los
productos software, es el entendimiento y aprecio del producto software. Esta calidad es la
culminación de un proceso, no puede esperarse en esta etapa una alta calidad si no hubo
preocupación por ella en las etapas anteriores.

Al finalizar el proceso de desarrollo y obtener un producto de calidad se espera que cumpla con:
 La satisfacción del cliente.
 La comercialización y uso masivo.
 Que responda a los requerimientos

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
-4-
  Desarrolle un buen rendimiento
 Sea fácil de usar.
 Que presente una real ayuda al usuario.
 Que se acompañe con la documentación necesaria de apoyo.

Cuando el producto entregado logra estas apreciaciones, se eleva el nivel de confianza y la

posición en el mercado, tanto del producto como de los responsables de su desarrollo.

Un producto de calidad es un producto probado durante el proceso de desarrollo, antes de ser

entregado al cliente.

4.2 Prueba en el Proceso Unificado

La prueba es el proceso de ejercitar un programa con la intención específica de encontrar errores
previos a la entrega al usuario final.

Para los sistemas grandes que se dividen en iteraciones se plantea un proceso general de
pruebas que comienza con la prueba de unidades de programas individuales, como son las
funciones y objetos, luego estas unidades se integran en subsistemas y sistemas, probando las
iteraciones integralmente. Una vez entregado el sistema al cliente se realizan las pruebas de
aceptación para comprobar que el sistema funciona según las especificaciones.

Cuando los sistemas son más pequeños, se distinguen menos etapas de prueba, las dos
actividades fundamentales de pruebas son:
 La prueba de componentes, es probar las partes del sistema, tratando de descubrir
defectos en los componentes.
 La prueba del sistema, probar el sistema integralmente, como un todo, que satisface los
requerimientos funcionales, los no funcionales y que no se comporta de forma inesperada.
Los defectos no detectados en los componentes aparecerán en esta instancia de prueba.

El proceso de pruebas del software tiene dos objetivos distintos:

1. Para demostrar al desarrollador y al cliente que el software satisface sus
requerimientos.
2. Para descubrir defectos en el software, que el comportamiento es incorrecto, no
deseable o no cumple su especificación.

4.2.1 Workflow de Prueba para Proceso Unificado de Desarrollo

En el flujo de trabajo de la prueba se verifican los resultados de la implementación probando cada
construcción, incluyendo construcciones internas e intermedias, también se prueban las versiones
finales del sistema a ser entregadas a terceros.

Los objetivos o propósitos que plantea el PUD para el workflow de prueba son:
 Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración
y las pruebas de sistema.
 Diseñar e implementar las pruebas creando los casos de prueba que especifican qué
probar, creando los procedimientos de prueba que especifican cómo realizar las pruebas y
creando componentes de prueba ejecutables, de ser posible.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
-5-
  Realizar las diferentes pruebas y manejar los resultados de cada prueba sistemáticamente.
Las construcciones en las que se detectan defectos son probadas nuevamente, luego de
ser implementado el arreglo al defecto, generando un nuevo ciclo de prueba.

¿Cuál es el papel de la prueba en el ciclo de vida del software?

Si bien las pruebas en el proceso es una etapa que generalmente se encuentra después de la
etapa de implementación, no es lo más conveniente, tal como lo expresáramos en los módulos
anteriores, es mejor detectar las fallas tempranamente. De este modo, las pruebas se encuentran
en todas las fases del ciclo de vida.

Las actividades principales de cada fase son:

 Fase de Comienzo: Planificación de pruebas iniciales, artefacto resultante, ―Plan de
prueba‖.
 Fase de Elaboración: Cuando la arquitectura ejecutable es verificada, artefacto resultante,
―casos de prueba‖.
 Fase de Construcción: Cuando se implementa el sistema, artefacto resultante,
―requerimiento de cambio‖.
 Fase de Transición: Concentra en defectos detectados durante el uso, artefacto resultante,
―Informe de evaluación de pruebas‖.

4.2.2 Metodología de Prueba

Si bien no hay una metodología establecida para la etapa de prueba de software, cualquiera sea
la metodología que se adopte debe tener en cuenta los siguientes principios:

 El proveedor del servicio debe aplicar una metodología disciplinada, documentada,

probada e interiorizada por todos los integrantes del equipo de pruebas involucrados en la
subcontratación. De la metodología se pueden evaluar aspectos como:
o simplicidad,
o lógica estructural,
o soporte conceptual,
o herramientas de apoyo y
o la independencia de aspectos técnicos del desarrollo, tales como los lenguajes de
programación, las plataformas tecnológicas o las arquitecturas del software a
probar.
 Capacidad tecnológica, depende del conocimiento y uso de estándares internacionales
de pruebas, los tipos de pruebas que podría ejecutar (funcionales, no funcionales, de carga
y estrés), la infraestructura tecnológica con que cuenta, la disponibilidad de un laboratorio
de pruebas y en algunos casos la automatización de su proceso de pruebas de software.
 Perfil y trayectoria del personal asignado al proyecto, el entrenamiento y la experiencia
que el grupo externo de pruebas tenga en metodologías y herramientas de pruebas es
fundamental para contratar el servicio con un proveedor específico.
 Estabilidad laboral y profesional del personal asignado al proyecto, las personas
asignadas al proyecto y a la actividad de pruebas deberán contar con una estabilidad
laboral que garantice la continuidad del proceso de pruebas, sin interrupciones por
inconvenientes laborales.
 Certificaciones, es importante contar con personas que acrediten con certificaciones sus
conocimientos.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
-6-
  Herramientas de apoyo al servicio de pruebas de software, existen diversas
herramientas que agilizan y automatizan algunas tareas de prueba, lo cual ayuda a los
tiempos del proceso.

En la metodología adoptada se debe tener en cuenta también, los aspectos a probar:

 Operabilidad—operar limpiamente
 Observabilidad—el resultado de cada caso de prueba es observable
 Controlabilidad—grado con el cual las pruebas pueden ser automatizadas y optimizadas
 Descomposición—las pruebas pueden ser dirigidas
 Simplicidad—reduce la lógica y arquitectura complejas para simplificar las pruebas
 Estabilidad—algunos cambios son requeridos durante las pruebas
 Comprensibilidad—del diseño

4.2.3 Tipos de Pruebas

Las pruebas se pueden clasificar teniendo en cuenta distintos aspectos, siendo numerosas y con
alto grado de detalle, para lo cual lo invito a profundizar en el tema con la lectura del libro
―Ingeniería de Software‖ de Sommerville, capítulos 23 y 24 y el capítulo 11 de libro ―El Proceso
Unificado de Desarrollo de Software‖.

Al ser tan numerosas las diferentes pruebas que se pueden realizar al software es conveniente
tener políticas para la prueba, dependiendo del tipo de software y su tamaño, teniendo en cuenta
que se debe adoptar al menos un tipo de prueba y hacerse al menos una vez. De forma
alternativa, las políticas de prueba pueden basarse en la experiencia de uso del sistema y
centrarse en aspectos operacionales. Por ejemplo:
 Deberían probase todas las funciones del sistema que se acceden a través de menús.
Prueba funcional.
 Deben probarse todas las combinaciones de funciones, como son los ingresos de datos.
Prueba de datos.
 El ingreso de datos debe hacerse con datos correctos e incorrectos.

El modelo de prueba que presenta Whittaker (Whittaker, 2002), es el siguiente:

Pruebas del sistema

Como vimos anteriormente, las pruebas del sistema integran dos o más componentes que
incorporan funcionalidades al sistema, realizando una prueba integral de su funcionamiento,
probando el incremento de software que será entregado al cliente.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
-7-
En la mayoría de los sistemas complejos, se plantean dos fases de pruebas distintas para el
sistema:
 Pruebas de integración, en la que el equipo de pruebas tiene acceso al código fuente del
sistema. Pruebas de ―Caja blanca‖
 Pruebas de entrega, se valida que el sistema cumpla con los requerimientos y que el
sistema es confiable, o sea que funciona correctamente. Pruebas de ―Caja negra‖.
Una vez integrado el sistema, se prueban las propiedades emergentes de él, como son el
rendimiento y la fiabilidad:
 Pruebas de rendimiento, es necesario diseñarlas para asegurar que el sistema pueda su
carga esperada, esto implica planificar una serie de pruebas en las que la carga se va
incrementando hasta que el rendimiento del sistema se hace inaceptable. Para realizar
esta prueba es necesario construir un perfil operacional, o sea un conjunto de pruebas que
reflejen el trabajo real que debería soportar el sistema. ―Prueba de estrés‖, normalmente
para sistemas distribuidos basados en red.

Cuando la arquitectura del sistema está basada en objetos se tendrán componentes reusables
que se deben probar en forma independiente e integrada. Si el sistema no está diseñado bajo
componentes, puede tener módulos o subsistemas que puedan ser considerados componentes.
Cuando un sistema identifica algún tipo de componente es necesario realizarle su prueba.
 Pruebas de componentes, proceso de pruebas de defectos, los responsables de estas
pruebas son los desarrolladores. “Pruebas unitarias”.

Los tipos de componentes que pueden probarse en esta etapa son:

o Funciones individuales o métodos de un objeto.
o Clases de objetos que tienen varios atributos y métodos.
o Componentes compuestos por diferentes objetos o funciones que tienen una
interfaz de comunicación.

Cuando el sistema cuenta con numerosos componentes que no son simples funciones u objetos,
sino que son componentes compuestos por varios objetos que intervienen, es necesario
establecer el acceso a estos componentes por medio de interfaces bien definidas. En estos casos
es necesario realizarles las pruebas necesarias:

 Pruebas de interfaces, se ocupa principalmente de probar que la interfaz del componente

se comporte de acuerdo con su especificación. Estas pruebas son importantes para el
desarrollo orientado a objetos y basado en componentes.

Existen diferentes tipos de interfaces entre los componentes del programa, por lo se encontrarán
distintos tipos de errores, como pueden ser:
 Interfaces de parámetros, componentes con paso de parámetros que pueden ser datos,
objetos o funciones a probar.
 Interfaz de memoria compartida, se comparten datos en un bloque de memoria. En este
caso se debe probar el componente que deja los datos y el que los toma.
 Interfaces procedurales, son interfaces en las que un componente encapsula un conjunto
de procedimientos que pueden ser llamados por otros componentes, es común en los
objetos y componentes reutilizables de un sistema.
 Interfaz de paso de mensajes, son las que un componente solicita un servicio de otro
componente por medio del paso de mensaje, el resultado también puede ser devuelto
como mensaje. Sistemas orientados a objetos y de arquitectura cliente – servidor.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
-8-
En sistemas complejos, los errores de interfaz es una de las formas de fallas en el sistema más
común, estos errores se clasifican en:
 Mal uso de la interfaz, error en el uso de la interfaz en el momento de la llamada de un
componente a otro. Error común en las interfaces de paso de parámetros.
 No comprensión de la interfaz, el componente que hace la llamada no comprende
claramente la especificación de la interfaz del componente al que llama, haciendo
suposiciones sobre su comportamiento, provoca un comportamiento inesperado en el
componente que la llama.
 Errores temporales, se producen en sistemas de tiempo real que utilizan una memoria
compartida o una interfaz de paso de mensajes. Tanto el productor de los datos como el
consumidor pueden operar a diferentes velocidades, accediendo así a datos no
actualizados o funciones que trabajan con datos erróneos.

4.2.4 Diseño de Casos de Prueba

En el Proceso Unificado de Desarrollo de Software, los casos de uso guían el proceso, marcando
el seguimiento de los requerimientos, de igual manera existen los casos de prueba que guían esta
etapa y que se diseñan en base a los casos de uso de los requerimientos.

El diseño de casos de prueba representa las entradas y salidas esperadas, es una parte de las
pruebas de componentes y sistemas que permite probar el correcto funcionamiento del sistema.

Como todo objetivo de pruebas, los casos de prueba tienen como propósito crear un conjunto de
casos de prueba efectivos descubriendo defectos en los programas y que muestren de alguna
forma que el sistema cumple con los requerimientos.

¿Cómo se hace el diseño de casos de prueba?

Para el diseño de casos de pruebas se realizan los siguientes pasos:

 Se selecciona una característica del sistema o componente que se desea probar.
 Se selecciona un conjunto de entradas que ejecutan dicha característica.
 Se documentan las salidas esperadas o rango de valores de salida.
 Se diseña una prueba automatizada capaz de probar que las salidas reales son las
mismas a las esperadas.

Para diseñar estos casos de prueba existen varias aproximaciones que se pueden seguir:
 Pruebas basadas en requerimientos, utilizadas principalmente en las pruebas del sistema,
donde los componentes responden a uno o más requerimientos que debe satisfacer el
sistema.
 Pruebas de particiones, utilizadas para grupos de datos que tienen características
comunes y son utilizados en la entrada de distintos componentes o módulos del sistema,
como son los datos numéricos o los rangos de las cadenas.
 Pruebas estructurales, utiliza el conocimiento de la estructura del sistema o programa que
ejecuten cada una y todas las estructuras utilizadas. En este caso de debería realizar al
menos una prueba de cada estructura, por ejemplo, las condicionales que determinan el
funcionamiento en base a una condición donde se espera un comportamiento por
verdadero y otro por falso. Las pruebas de camino es una de las convenientes a utilizar en
las pruebas estructurales, cuyo objetivo es probar cada camino independiente de los
componentes o programas tratando de detectar las posibles fallas de cada camino. Hay

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
-9-
 que tener en cuenta que el número de caminos de un programa es proporcional al tamaño
del mismo.

Automatización de las pruebas

La etapa de pruebas de un sistema es una actividad costosa, laboriosa y lleva tiempo en ser
ejecutada, es por ello que muchas veces, se minimizan o no se realizan llevando esto a riesgos de
mal funcionamiento del sistema y a entregar un producto que no es de calidad. Esta será siempre
la razón por la cual la automatización de las pruebas es necesaria, además de aportar una ventaja
importante al proyecto.

Las herramientas de prueba son uno de los primeros software a realizar, aunque en la actualidad
los entornos de programación la traen incorporadas o bien se pueden utilizar herramientas
externas al entorno que acompañan y permiten diseñar los casos de prueba ofreciendo una serie
de facilidades y uso que pueden reducir significativamente el tiempo y costo de esta etapa.

Es claro que la ―Verificación y Validación‖ de un sistema crítico tiene mucho en común con la
validación de cualquier otro tipo de sistema, así los V&V deben demostrar que el sistema satisface
su especificación y cumplen con los requerimientos del cliente. No obstante en los sistemas
críticos se requiere un alto nivel de confiabilidad, para lo cual son necesarias pruebas y análisis
adicionales. Existen dos razones que justifican por qué esto es tan necesario:

1. Costos de fallos de ejecución, los costos y consecuencias de las fallas de estos

sistemas son potencialmente más grandes y de consecuencias más graves que los no
críticos. Estas fallas pueden llevar a catástrofes y a la quiebra de una organización.
2. Validación de los atributos de confiabilidad, es posible que se deba realizar una
demostración de su funcionamiento o simulación del mismo a los clientes, en la cual se
deben probar las características de confiabilidad, tales como disponibilidad, fiabilidad,
seguridad y protección. En este caso, para certificar el buen funcionamiento, es necesario
diseñar y llevar a cabo procedimientos de V&V especiales capaces de recoger las
evidencias sobre la confiabilidad de los sistemas.

Garantía de la seguridad

El proceso de la fiabilidad y el de la garantía de la seguridad tienen objetivos distintos. La principal

diferencia radica en las mediciones que se pueden realizar, en el caso de la fiabilidad se puede
especificar en forma cuantitativa utilizando alguna métrica, pudiendo controlar si ha alcanzado el
nivel requerido de fiabilidad, en cambio en la seguridad no pueden especificarse de forma
cuantitativa, no puede medirse cuando se prueba el sistema. Por lo tanto, la garantía de seguridad
está íntimamente relacionada con establecer un nivel de confianza en el sistema que podría variar
desde ―muy bajo‖ hasta ―muy alto‖. Esto se basa fundamentalmente en una cuestión profesional
basado en evidencias sobre el sistema, su entorno y su proceso de desarrollos, como así también
está basada en la experiencia de la organización que desarrolla el sistema.

Conclusión del tema de pruebas de los sistemas

Es claro que la gestión de la calidad provee una comprobación independiente de los procesos de
desarrollo de software, para ello se debe dar importancia a la actividad de pruebas, conociendo
las características del sistema, los distintos tipos de prueba que puede realizar y las herramientas
a utilizar para garantizar que el sistema cumple con los requerimientos, es fiable y posee la debida
seguridad.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 10 -
La tarea de prueba debe ser realizada por personas que no sean los responsables del desarrollo
del sistema, pueden ser internos o externos de la organización, pero deben garantizar continuidad
e idoneidad en su actividad, es mucho mejor contar con gente certificada en ―testing‖ para
garantizar el trabajo.

La gestión de calidad es ejecutada por personas que ejerzan autoridad en el tema, pudiendo
rechazar un producto si no cumple con las normas establecidas en las políticas de calidad de la
organización o del cliente.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 11 -
Unidad 5: Modelos de Calidad de Software
5.1 Calidad del Proceso
En la evolución del software de los últimos años, saliendo de la crisis del software y la
incorporación de la Ingeniería de software y la Ingeniería de requerimientos, la calidad del
software se ha mejorado significativamente. En gran parte se debe también a la incorporación de
nuevas técnicas y tecnologías en el proceso de desarrollo como es el paradigma orientado a
objetos y el soporte de herramientas CASE. Todo este avance tecnológico y de proceso está
acompañado con una mayor conciencia de la importancia de la gestión de calidad y de la
adopción de técnicas y normas que ayudan a garantizar la calidad del producto final a través de la
mejora continua de los procesos.

Incorporado el concepto de calidad se puede asegurar que los resultados de un proyecto de

software se miden según las siguientes variables:
 Alcance - (Funcionalidad)
 Tiempo - (Calendario)
 Esfuerzo - (Presupuesto - Costo)
 Calidad - (Criterios de Aceptación)

La evolución de la calidad en el tiempo:

D Gestión total de la
e calidad
s
a
r Aseguramiento de
r la calidad
o
l Inspección Control
l de la calidad
o

‗20 ‗40 ‗60 ‗80 2000

Tiempo

En una visión actual de la calidad de software, La Gestión Total de la Calidad es la actividad

sistemática y científica que, involucrando a toda la organización, se focaliza en la satisfacción de
los clientes

En un concepto moderno, la calidad no la define ni el productor ni las normas, la define el cliente.

Como vimos en la unidad 4, la calidad del software es un concepto complejo que no es

comparable totalmente con el de la manufactura de otros productos. El software es un producto
con características especiales, se desarrolla no se fabrica, es un producto lógico y no físico y no
se degrada con el uso.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 12 -
5.1.1 Concepto de Calidad de Proceso
El concepto de calidad de software significa cuidar todos y cada uno de los elementos
enumerados en la definición de software y no sólo el código fuente.

En la Unidad 4, vimos la calidad del producto de software y su relación estrecha con el proceso de
desarrollo, esto es simple de entender ya que el producto final del proceso es el software, por lo
tanto no se puede hablar de calidad de uno de los dos, sino de ambos.

La ―Garantía de la calidad‖ o ―Aseguramiento de la calidad‖ (QA, Quality assurance), es el proceso

que define cómo lograr la calidad del software y cómo la organización de desarrollo conoce el
nivel de calidad requerido en el software. El proceso de QA se ocupa ante todo de definir o
seleccionar los estándares que deben ser aplicados al proceso de desarrollo de software o al
producto software.

Se pueden definir dos estándares como parte del proceso de garantía de calidad:

1. Estándares de producto, se aplican sobre el producto software que se comienza a

desarrollar, incluyen estándares de documentación y estándares de codificación.
2. Estándares de proceso, definen los procesos que deben seguirse durante el desarrollo
del software y de la documentación que debe acompañarlo.

Los estándares de producto se aplican a las salidas del proceso software y los estándares de
proceso incluyen actividades de proceso específicas que garantizan que se sigan los estándares
de producto.

¿Por qué ocuparse de la calidad?

La evolución del concepto de calidad en los procesos ha definido las ventajas que trae
implementar calidad en los procesos, estas ventajas son las que justifican el porqué una
organización debe ocuparse de la calidad, porque:
 Es un aspecto competitivo.
 Es esencial para sobrevivir.
 Es indispensable para el mercado internacional.
 Es el equilibrio entre costo – efectividad.
 Retiene clientes e incrementa beneficios.
 Es el sello de clase en el mundo de los negocios.

Si observamos el gráfico de la evolución de la calidad a partir de 1920, notas 3 hitos importantes,

Inspección Control de la calidad, Aseguramiento de la calidad y la Gestión total de la calidad.

Inspección Control de la calidad

La primer relación entre el cliente y el proveedor de un producto fue una tarea artesanal, ya que la
persona se comunicaba directamente con el artesano, le solicitaba lo que quería y éste lo hacía a
medida, como por ejemplo el sastre que hacía los trajes a medida del cliente, esta comunicación
tenía como resultado alta calidad y elevado costo.

La producción industrial sustituye a la artesanal. Entonces, los costos se reducen drásticamente,

sobre la base de dos aportaciones:

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 13 -
  La Normalización de Piezas, concepto introducido por Samuel Colt en 1820
 La Cadena de Producción concepto introducido por Henry Ford en 1913.

Al instaurarse la cadena de producción aparece el primer problema de calidad. Era imprescindible

que las piezas producidas fuesen conformes con su especificación.

Surge así, la primera definición de Calidad: ―conformidad con las especificaciones‖. El concepto
adoptado fue, a una mayor conformidad acompañará un menor número de reprocesos y
desechos, con lo que el costo del producto se reducirá, lo que puede traducirse en mayor margen
comercial o en un precio menor, con el consiguiente aumento de competitividad.

Aparecen entonces los procedimientos de ―Control de Calidad”, fundamentados en métodos

estadísticos. De este modo, la función de calidad, en su concepción clásica, se limita a la
realización de una serie de experimentos que tienen como objetivo la verificación de la
concordancia de los diferentes componentes y dispositivos a su especificación.

Se consideraba al control de calidad fundamentalmente como una actividad de inspección,

limitada a la recepción de materias primas, procesos productivos y, más recientemente, a la
auditoría de calidad del producto terminado.

Son los técnicos quienes definen la calidad del producto y del proceso.

Aseguramiento de la calidad - Cadena de reacción de Deming

W. Edwards Deming (1900 – 1993) estadístico y asesor en gestión de la calidad, de origen

norteamericano, es conocido principalmente porque ayudó a revitalizar la industria japonesa en los
años posteriores a la Segunda Guerra Mundial. En la década de 1980 fue un consultor muy
solicitado por la industria norteamericana. Conocido como el padre de la calidad.

En agradecimiento a su contribución a la economía japonesa, la Unión de Ciencia e ingeniería

Japonesa (JUSE) instituyo el Premio Anual Deming para las aportaciones a la calidad y fiabilidad
de los productos.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 14 -
La sección Metropolitana de la Asociación Americana de estadística estableció en 1980 el premio
anual Deming para la mejora de la calidad y la productividad.

Cuando el Dr. W. Edwards Deming fue invitado al Japón en el verano de 1950, se encontró con un
país totalmente destruido por la guerra.

Hizo al Japón dos recomendaciones, y les aseguró que si las aplicaban, lograrían transformarse
en un país próspero y con mejor calidad de vida. En cinco años el Japón se había transformado
en el primer fabricante de barcos del mundo; para la década de los '70 había alcanzado su
liderazgo en productos electrónicos. Con disciplina y método, el Japón había hecho realidad lo
que el Dr. Deming pronosticó en 1950.
CADENA DE DEMING
En primer lugar, Deming les aseguró que:
 al lograr la calidad,
 sus costos se reducirían al producir con menos errores, con menos tardanzas, con menos
obstáculos,
 reduciendo el reprocesamiento y
 haciendo mejor uso de los insumos.

Ello los llevaría a aumentar su productividad, hacerse más competitivos, lo que les permitía
ganar el mercado con productos de mejor calidad a menor precio.

De esa forma se aseguraba:

 la permanencia en el negocio;
 teniendo como resultado la generación de más empleo y
 una mayor prosperidad.

Esta recomendación ha llegado a ser conocida como la “Reacción en Cadena de Deming”, que
se puede representar con la siguiente gráfica:

Al mejorar la calidad se transfieren las horas- hombre y las horas-máquina malgastadas, a la

fabricación de producto bueno y a dar un servicio mejor.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 15 -
El resultado es una reacción en cadena:
 se reducen los costos,
 se es más competitivo,
 la gente esta más contenta con su trabajo,
 hay trabajo y más trabajo.

Deming deja un postulado de 14 puntos que se deben seguir para conseguir la calidad en la
producción y fabricación de productos.

Otro aporte importante realizado por Deming, es el ―Círculo de Deming‖, el cual plantea 4 acciones
indispensables:
 Plan – planificación.
 Do – hacer
 Check – verificar
 Act - actuar

Este círculo nos lleva a la ―Mejora continua‖ de los procesos, ya que una vez diseñados y puestos
en práctica, se verifican y se realizan los cambios que sean necesarios para lograr una mejora en
nuevos proyectos. Estas mejoras se realizan continuamente, es por ello que recibe dicho nombre.

Veamos la imagen que lo representa en el mundo.

Fuente: Wikipedia, http://es.wikipedia.org/wiki/C%C3%ADrculo_de_Deming

Por último en la evolución de calidad tenemos la ―Gestión total de la calidad‖

Calidad total

La Calidad Total incluye todas las funciones y fases que intervienen en la vida de un producto o
servicio, no sólo al producto en sí, sino a la gestión de la organización en su globalidad, poniendo
en juego todos los recursos necesarios para la prevención de los errores, involucrando a todo el
personal, sistematizando las múltiples relaciones proveedor-cliente (interno y externo), mejorando
el clima y las relaciones, reduciendo las pérdidas provocadas por una gestión insuficiente.
Es importante destacar dos conceptos fundamentales:
 Tiene en cuenta la totalidad de las necesidades de los clientes con el objetivo final de la
satisfacción de sus necesidades y expectativas.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 16 -
  Atiende a los procesos que se utilizan en la organización para la producción, fabricación o
desarrollo de un producto.
El concepto de cliente interno lo introduce Deming, como toda persona que solicita o necesita algo
de otra es un cliente, por lo tanto, lo más probable es que cada miembro de la organización tenga
más de un proveedor y más de un cliente internos. Si cualquier eslabón falla, el resultado del
proceso será defectuoso y el trabajo de la unidad o departamento habrá perdido efectividad y
calidad para el cliente externo.

ISO 9000

ISO 9000 es una Norma con un conjunto de estándares internacionales que se pueden utilizar en
el desarrollo de un sistema de gestión de calidad de todas las industrias, pudiéndose aplicar tanto
a las organizaciones manufactureras como a las de servicios.

ISO 9001 es el estándar más general y se aplica al proceso de calidad de diseño, desarrollo y
mantenimiento de productos. Hay documentos que interpretan ISO 9001 y ayudan a entender
mejor la norma, como lo es ISO 9000-3, para el desarrollo de software.

ISO 9001 no es un estándar específico para el desarrollo de software, pero sus principios son
generales por lo que pueden aplicarse a este, ya que describe aspectos del proceso de calidad,
estándares y procedimientos, todo debe documentarse en un manual de calidad organizacional.
En cuanto a los procesos, incluido el de desarrollo de software, debe incluir una descripción de la
documentación requerida, entre ellos el documento de Especificación de Requerimientos de
Software, ERS, donde se demuestra que el proceso definido se ha seguido por cada
requerimiento.

¿Qué es y qué no es ISO 9001:2000?

 No es un texto de ley.
 No es un texto que imponga los medios aplicables para el cumplimiento de sus requisitos.
 No es un texto que exija la implantación de un sistema documental complejo y difícil de
gestionar.

 Es un instrumento de adhesión voluntaria.

 Es un texto aplicable a cualquier tipo de organización independientemente de cual sea su
tamaño y su grado de implantación en el mundo.
 Es un texto que exige compromisos.

Objeto

ESPECIFICAR los requisitos de un Sistema de Gestión de la Calidad, cuando una organización:

 Necesita demostrar su capacidad para proporcionar de forma coherente
productos/servicios que satisfagan los requisitos del CLIENTE y los reglamentarios
aplicables.
 Aspira a aumentar la satisfacción del CLIENTE a través de la aplicación eficaz del sistema.
Requisitos
 Sistema de gestión de la calidad.
 Posee requisitos generales.
 Establece los requisitos de la documentación, que son:
o Generalidades

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 17 -
 o Manual de la calidad
o Control de los documentos
o Control de los registros

Otros requisitos importantes a destacar de la norma son: MEDICIÓN, ANÁLISIS Y MEJORA

No se puede mejorar lo que no se puede medir, por lo que es necesario identificar los indicadores
del proceso que luego de hacer un análisis de los resultados se puede establecer una mejora.

Los aspectos claves se pueden representar en la siguiente figura:

Su enfoque basado en procesos presenta cuatro pasos fundamentales:

 Identificar los procesos.
 Determinar su secuencia e iteración.
 Establecer criterios para controlarlos
 Realizar seguimiento, medición y análisis
 Para lograr la Mejora continua.

5.2 Modelo de calidad CMM

5.2.1 ¿Qué es el Modelo de calidad CMM?

El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de

evaluación de los procesos y del nivel de maduración de una organización. Inicialmente, fue
creado para los procesos relativos al desarrollo e implementación de software por la Universidad
Carnegie-Mellon para el SEI (Software Engineering Institute, centro de investigación y desarrollo
patrocinado por el Departamento de Defensa de los Estados Unidos de América y gestionado por
la Universidad Carnegie-Mellon), siendo así ―CMM‖ una marca registrada del SEI

El término CMM se referir a:

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 18 -
  La visión general de los modelos basados en la madurez de las capacidades: Modelo de
Capacidad y Madurez
 El modelo de calidad específico para desarrollo de software: SW-CMM

En 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América (en
particular del Departamento de Defensa, DoD), desarrolló una primera definición del modelo de
madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este
trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se
publicó en febrero de 1993.

CMM, es un esquema que representa un camino de mejoramientos, permite determinar la

madurez y evaluar las capacidades de las organizaciones que desarrollan software, recomendado
para las organizaciones que quieren incrementar la capacidad de su proceso de desarrollo.

Relación de CMM con el proceso de desarrollo:

Hasta ahora hemos visto el concepto de proceso, pero ¿qué es un proceso repetible?

 ‗Proceso‘ vs. ‗Proceso Definido, Documentado y Repetible‘ – parecen similares pero son
dos cosas TOTALMENTE DIFERENTES.
o Consistencia a través y entre proyectos reduce en el entrenamiento y los startups
o Aumenta el entendimiento del proyecto debido a la consistencia.
 Work products y documentos
 Planificación y reportes
 Métodos y técnicas
 Reduce la transición de recursos entre los proyectos
 Reducen el costo/esfuerzo a causa de componentes reusables
 ―alimentan‖ a la organización con sus propias ―best practices‖

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 19 -
  Reducen la dependencia del conocimiento individual

Una premisa de la mejora continua de proceso fue planteada por Sheri Clark, BIT y es la
siguiente:

“Si Ud. puede garantizar la calidad del proceso usado por una organización, entonces Ud. puede
garantizar la calidad de los productos y servicios generados por ese proceso”.

La mejora continua debe ser una decisión institucional, debe adquirirse una cultura dentro de ella
que lleve a trabajar bajo procesos y los cumpla como una forma natural del desempeño de sus
actividades.

La institucionalización del proceso, es la infraestructura y la cultura organizacional que soporta

métodos, prácticas y procedimientos, aún después que quienes lo definieron ya no están. Para
lograrlo se debe tener en cuenta:

 Compromiso de la gerencia y sponsorship

 Recursos asignados
 Entendido e integrado horizontal y verticalmente
 Tiene 3 meses o mas ―In place‖

La mejora en los proceso trae a la organización ventajas, es por ello que todos quieren hacer su
mejor trabajo y producir un trabajo de alta calidad, pero no todos tiene la infraestructura, el
entrenamiento y el soporte para lograrlo. Para consistentemente producir un producto o servicio
de alta calidad todos deben ser capaces en hacer su trabajo.

Parece que no es posible pensar en organizaciones donde no se realice bien el trabajo, no

obstante es una constante en la mayoría de las organizaciones de desarrollo de software, sobre
todo si no están trabajando bajo la consigna de calidad.

¿Qué características tienen estas organizaciones donde no todos son capaces de hacer un
buen trabajo?

 El líder del proyecto hace malas planificaciones y toma decisiones erradas respecto a los
recursos.
 No se cumplen las fechas de entrega de los proyectos
 Los requerimientos presentan cambios constantes.
 Los errores no se corrigen antes de que estén en producción
 No aprenden de los errores pasados.

Parte de la respuesta es: EL PROCESO DE LA ORGANIZACIÓN ES INMADURO

5.2.2 Organizaciones Maduras Vs. Inmaduras

Las organizaciones inmaduras presentan características bien definidas, como son:
 Proceso improvisado durante el proyecto de desarrollo de software
 Procesos aprobados son ignorados a la hora de desarrollar el software
 Reactivas, no pro-activas, esperan a que pase algo para implementar el proceso

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 20 -
  Presupuestos y planificaciones no realistas
 Calidad del producto sacrificada en pos de la entrega, el tiempo siempre es un
determinante que hace que se sacrifique la calidad del producto y que no se cumpla con el
proceso.
 No se miden los objetivos de calidad, ya sea porque no se saben o porque no le dan la
importancia que tienen.

Las características que presentan las organizaciones maduras son:

 Comunicación y coordinación entre los diferentes grupos de trabajo de la organización y

externos.
 Todos los trabajos son realizados de acuerdo a un plan.
 Posee la habilidad para administrar los procesos de desarrollo y mantenimiento del
software.
 Las prácticas son consistentes con los procesos y los procesos son debidamente
comunicados y compartidos por todos.
 Los administradores monitorean los procesos, la calidad del producto y la satisfacción del
cliente.
 Los procesos son actualizados cuando son necesarios
 Los roles y responsabilidades están bien definidos
 La planificación y los presupuestos son realistas y basados en la performance histórica de
otros proyectos. Los resultados esperados pueden alcanzarse en costos, tiempo y calidad
del producto.
 La gerencia formalmente se compromete.
 Se sigue un proceso disciplinado, todos los participantes entienden el valor de hacerlo y
existe la infraestructura necesaria para darle soporte.

5.2.3 Esquema de Madurez

Conceptos fundamentales que plantea CMM:
 Capacidad del proceso, describe el rango de resultados esperados que se pueden
alcanzar aplicando un proceso de desarrollo de software.
 Desempeño del proceso, resultados reales alcanzados siguiendo el proceso de
desarrollo de software.
 Madurez del proceso, alcance para el que un proceso específico es efectivo y está
definido, gerenciado, medido y controlado.
 Institucionalización, requiere de una infraestructura y una cultura corporativa que soporte
los métodos, prácticas y procedimientos del negocio que sobreviva al alejamiento de los
que lo definieron en un principio, o sea, las personas pueden irse pero los procesos
quedan definidos y se transmiten dentro de la organización por los que quedan.

¿Cuáles son las ventajas de la mejora de procesos?

 La performance es más realista y precisa

 El éxito depende del proceso y de los skills de los equipos de trabajo
 Hay un soporte tecnológico a los procesos
 Las métricas son estándares
 La información histórica es más precisa y sirve de base para estimaciones y predicciones
 Más visibilidad en los procesos, más precisión para administrar el progreso de los
proyectos

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 21 -
  Los riesgos son minimizados

La realización de estos beneficios contribuye directamente a alcanzar las necesidades y

exigencias de nuestros clientes

Implementar el modelo CMM no ha sido una tarea fácil de lograr ni de bajo costo para las
organizaciones, es por ello que no todas podían optar por este modelo a la hora de decidir trabajar
en calidad. Una de la alternativa viable y más usada es ISO 9001.

En una visión global de CMM podemos establecer que:

 Encuentra dificultad para establecer las mejoras a introducir.
 La necesidad de una estrategia de mejora, o sea marcar un camino a recorrer.
 Ordena las etapas de forma que la mejora de una etapa constituye el fundamento para otra
que la sigue.
 Guía para ganar control en los procesos.
 Determina la real madures de los procesos e identifica los puntos críticos.
 Se focaliza en un conjunto limitado de actividades.

5.2.4 Áreas Claves por Nivel

Además, este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas
Clave de Proceso (KPA - Key Process Área). Para cada área de proceso define un conjunto de
buenas prácticas que habrán de ser:
 Definidas en un procedimiento documentado
 Provistas (la organización) de los medios y formación necesarios
 Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
 Medidas
 Verificadas

Tenga en cuenta que CMM como modelo es:

 Descriptivo
 Normativo
 No prescriptito.

Las Áreas de Proceso se agrupan en cinco "niveles de madurez", una organización que tenga
institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha
alcanzado ese nivel de madurez.

Los niveles son:

1. Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el

desarrollo y mantenimiento de software. El éxito de los proyectos se basa la mayoría de las
veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre
retrasos y costos elevados, fuera del presupuesto. El resultado de los proyectos es
impredecible. Todas las organizaciones que no trabajan en calidad están en Nivel 1.

Claves del nivel 1: selección, desvinculación, desarrollo y/o retención del personal se realiza
fuera de los cánones de CMM.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 22 -
 2. Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas
de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la
calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.

Claves del nivel 2: se concentra en cuestiones gerenciales y es la base para encarar las
cuestiones técnicas en el Nivel 3.

3. Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones
disponen de correctos procedimientos de coordinación entre grupos, formación del
personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los
procesos. Se implementan técnicas de revisión por pares (peer reviews).

Claves del nivel 3: se construye sobre las bases de gestión de proyectos del nivel anterior. El
proceso de software está dominado por los aspectos de diseño, es una actividad de conocimiento
intensiva.

4. Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de

métricas significativas de calidad y productividad, que se usan de modo sistemático para la
toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.

Claves del nivel 4: la capacidad del proceso es predecible, las metas son cuantitativas midiendo
calidad y productividad, se reúnen y analizan datos disponibles, se predicen cambios en procesos
y calidad de productos, los proyectos estrechan la variación del proceso.

5. Optimizado. La organización completa está volcada en la mejora continua de los

procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.

Claves del nivel 5: la capacidad del proceso es la ―Mejora continua‖, identifica fortalezas y
debilidades, realiza análisis de costo beneficio de nuevas tecnologías, innovaciones que explotan
las mejores prácticas de la ingeniería de software, análisis de defectos y evaluación del proceso
de software.

Es así como el modelo CMM establece una medida del progreso, que está dada conforme al
avance en niveles de madurez. Cada nivel a su vez cuenta con un número de áreas de proceso
que deben lograrse. El alcanzar estas áreas o estadios se detecta mediante la satisfacción o
insatisfacción de varias metas claras y cuantificables. A excepción del primer nivel (este nivel no
se certifica porque todas las organizaciones están en nivel 1), cada uno de los restantes Niveles
de Madurez está compuesto por un cierto número de Áreas Claves de Proceso, conocidas a
través de la documentación del CMM por su sigla inglesa: KPA.

Veamos el esquema de CMM en la siguiente gráfica:

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 23 -
5.3 Implementación del Modelo de calidad CMM
No todas las organizaciones están en condiciones de implementar un modelo CMM, ya sea por
falta de infraestructura o por los costos; a veces no justifica implementar un modelo que lleva
mucho tiempo y es muy costoso en empresas en las que su volumen de facturación no permite tal
inversión.

Así como se plantean ventajas en la utilización de la ingeniería por componentes, en la

reutilización de los mismos, también se plantean ventajas en los procesos comunes capaces de
ser repetidos en N proyectos de la organización.
Se puede utilizar el modelo CMM como guía para tratar de implementar nuevos procesos, no
siendo necesarios comenzar por el nivel 1 y seguir hasta el nivel 5, cada organización toma el
camino y el nivel de inicio que crea más conveniente de acuerdo a sus necesidades y
posibilidades.

En muchos sentidos, la implementación de procesos comunes para la administración de proyectos

es la parte más difícil, ya que la organización carece de madurez y se debe comenzar desde cero,
para llegar a certificar un Nivel 2, una vez logrado el desafío es mantenerse y no volver al nivel 1.

Una vez lograda la conciencia de calidad e internalizado en el uso de los procesos en las
actividades de trabajo cotidianos es más fácil avanzar, ya que se cuenta con una base más sólida
de conocimientos sobre calidad y el trabajo bajo procesos.

Todos los cambios culturales que implica avanzar de un nivel a otro con mucho trabajo y tiempo
para lograrlo.

No es necesario certificar los niveles en forma secuencial, algunas organizaciones optan por
certificar el Nivel 2, luego el 3 y saltar al 5.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 24 -
¿Qué es una certificación? ¿Para qué sirve un producto certificado?

La certificación es la forma de ―Validación‖ que una entidad externa realiza a la organización para
aprobar o desaprobar estándares de calidad utilizados en los procesos.

Algunas empresas emprenden el camino hacia una certificación con la convicción de que la
mejora de sus procesos y metodologías de trabajo son una vía más directa y segura hacia el éxito
comercial futuro. Estas empresas sitúan al concepto de calidad en el centro de su estrategia,
están dispuestas a invertir recursos no sólo para alcanzar la certificación sino también para
sostener y optimizar el modelo de calidad en el largo plazo.

Otras empresas en cambio, buscan en la certificación la credencial que le abran nuevas

oportunidades de negocio, especialmente para poder entrar en mercados que exigen este tipo de
avales como requisito básico. En consecuencia, estas empresas visualizan a la formalización y
mejora de sus actividades como una tarea ligada al proceso externo de certificación, como
beneficio de negocio, que al proceso interno de desarrollo y entrega de productos y servicios
como un proceso de calidad y satisfacción del cliente en la mejora continua.

Ambas perspectivas son válidas y pueden servir a los fines de la compañía, aunque es preferible
el primer enfoque, ya que es el que sostiene con más solidez el concepto y fin de la calidad.

Las certificaciones en las PYMES del sector software

Las empresas desarrolladoras de software tienen una tendencia natural hacia la formalización de
sus procesos; esto se puede atribuir en parte al grado de profesionalización de sus directivos y en
parte por la afinidad con el uso de metodologías. No obstante, es común encontrar pequeñas
empresas del sector software que cuentan con sólidos procesos, muchas veces documentados y
soportados por herramientas informáticas, que no cuentan con validaciones externas de calidad.

Una decisión que la empresa de software debe adoptar es qué modelo de calidad es el que mejor
se adapta a sus necesidades. Si bien los dos modelos ISO y CMM son estándares de calidad, ISO
es una norma certificable enfocada en los procesos internos y externos, mientras que CMM es un
modelo de madurez específicamente enfocado en los procesos de desarrollo de software.
Ambos modelos pueden ser complementarios e igualmente válidos a nivel nacional e
internacional, aunque para la mayoría de las empresas del sector, CMM es la opción más
ajustada. Para algunas empresas de servicios de desarrollo, como por ejemplo las fábricas de
software, el modelo ISO podría ser el más adecuado en tanto sean más importantes sus procesos
de relación con el cliente y de flujo interno de requerimientos, que la construcción del software en
sí mismo.

5.3.1 Cómo desarrollar e implementar las áreas claves del Nivel 2 de

CMM en una organización
Para el nivel 2 – Nivel Definido, es necesario tener en cuenta las actividades necesarias para su
correcta implementación:

 Hacer foco en el proceso de la organización.

 Definir los procesos de la organización.
 Tener un programa de entrenamiento.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 25 -
  Una gestión integrada de software.
 Aplicar una ingeniería de producto de software.
 Establecer una coordinación intergrupal.
 Realizar una revisión por pares.

- Hacer foco en el proceso de la organización. Tiene como propósito establecer la responsabilidad

organizacional para las actividades necesarias del proceso de software que mejoran la capacidad
global del proceso de software.

- Definir los procesos de software. Tiene como propósito desarrollar y mantener un conjunto de
activos que mejoran el desempeño de posproyectos y proveen una base para la mejora a largo
plazo.

- Tener un programa de entrenamiento. Tiene como propósito desarrollar las habilidades y

conocimiento de los integrantes del equipo de trabajo, para que desempeñen sus roles con
eficiencia y efectividad, o sea tengan una adecuada capacitación.

- Una gestión integrada de software. Tiene como propósito integrar las actividades de la Ingeniería
de software y la gestión en un proceso de desarrollo del software adaptado del proceso estándar.

- Aplicar una Ingeniería de producto. Tiene como propósito ejecutar consistentemente un proceso
de Ingeniería bien definido que integre todas las actividades de la ingeniería de software para
producir un producto de calidad.

- Establecer una coordinación intergrupal. Tiene como propósito establecer un medio para que el
grupo participe activamente con otros ingenieros tratando de lograr mejores condiciones de
satisfacción efectiva y eficiente de las necesidades o requerimientos del cliente.

- Realizar una revisión por pares. Tiene como propósito eliminar tempranamente los posibles
defectos del software y del proceso.

Críticas a CMM

Frecuentemente se crítica al modelo CMM por no ser más específico en la definición de los
procesos, ya que para guiar a las organizaciones a definir y mejorar sus procesos indica qué
actividades han de realizar, pero nada sobre cómo hacerlo. Esto es así tanto en lo referente a la
ingeniería como a las herramientas o técnicas de gestión, aunque presenta una excepción en las
revisiones por pares (peer reviews).

Del mismo modo, aunque insiste continuamente en la necesidad de las métricas, no da ninguna
guía concreta del tipo de métricas que son aceptables para una correcta práctica profesional,
dejando a criterio de la organización la definición de la métrica que puede considerar como
correctas.

Los técnicos se quejan a menudo de su burocracia, de la enorme carga de "papeleo" que impone
el modelo, viéndolo más como un mecanismo de control por la dirección que una herramienta que
les ayude en su trabajo, convirtiéndose en algo imposible de poder mantener actualizado.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 26 -
CMMI
En un intento de integrar los modelos que se habían desarrollado, incluyendo sus propios modelos
(CMM-SW, SE-CMM, IPD-CMM), el SEI se embarcó en un nuevo programa para desarrollar un
modelo de capacidad integrado, el CMMI.

El CMMI sustituye el software y a los sistemas de ingeniería basados en CMM e integra a otros
modelos de ingeniería, caracterizándose por tener dos instancias, en etapas y continuo, además
de tratar algunas de las debilidades del CMM de software.

El modelo CMMI intenta ser un marco de trabajo para la mejora del proceso que sea aplicable en
un amplio abanico de compañías de diversas disciplinas y cuerpos de conocimiento. Su versión en
etapas es compatible con el CMM de software, permitiendo un desarrollo del sistema de la
organización, la gestión de los procesos a valorar y su asignación a un nivel de madurez entre 1 y
5, tal como el que plantea CMM. Su versión continua permite una clasificación más detallada y
considera 24 áreas de procesos.

Las organizaciones pueden usar CMMI para ayudar a:

 Fijar objetivos y prioridades que proceso de mejoras continuas
 Procesos de mejora
 Dar guías para asegurar estabilidad y capacidad y madurez al proceso.

Etapas vs. Continuos

Se exponen dos representaciones, atendiendo a las características más importantes de mejora del
proceso:
 Por herencia del CMM tradicional
 Representantes de cada tipo de representación fueron parte del grupo de desarrollo de
CMMI
 Seleccionar un sólo enfoque se convertía en algo demasiado difícil
 Se mantuvo un compromiso inicial de tener diferentes representaciones con un modelo
equivalente en contenidos

Fuente: Kudlick T, Cubed, S.

Carnagie Mellon - Software Engineering Institute, CMMI Continuous and Staged Representation: Why
They are Both Correct and Both Incorrect

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 27 -
¿Cuáles son las disciplinas de CMMI?

Se identifican cuatro cuerpos de conocimiento disponibles cuando se selecciona el modelo CMMI:

 Systems engineering (SE):

o Cubre el desarrollo de todo un sistema, que puede o no incluir al software
o Enfocado en transformar las necesidades del usuario, sus expectativas y
restricciones en soluciones de producto y
o Dar soporte a estas soluciones a lo largo de la vida del producto.

 Software Engineering (SW)

o Cubre el desarrollo de sistemas de software
o Enfocado en aplicar sistemáticamente, disciplinadamente y en forma cuantitativa
los enfoques de desarrollo, operación y mantenimiento de software.

 Integrated Product and Process Development (IPPD):

o Enfoque sistemáticamente que alcanza una colaboración coordinada de los
stakeholders principales a lo largo de la vida del producto para satisfacer mejor las
necesidades y requerimientos del cliente.
o Los procesos que soportan el enfoque IPPD están integrados con otros procesos
en la organización.

 Supplier Sourcing (SS):

o Proyectos que usan proveedores que llevan a cabo sus funciones o agregan
modificaciones a los productos que son específicamente requeridas por el proyecto.
o Esta disciplina incluye adquirir productos desde proveedores bajo esta
circunstancia.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 28 -
Unidad 6: Métricas
6.1 Métricas
Las revisiones de la calidad son caras, consumen tiempo e inevitablemente retrasan la entrega del
software; este proceso se puede acelerar utilizando herramientas que procesen el diseño de
software o el programa y generen valoraciones automáticas de la calidad del software. Estas
valoraciones permiten controlar y comprobar el grado de calidad requerido y obtenido, destacando
las partes en donde no se ha alcanzado para revisarlas y poder mejorarlas.

Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano
requerido por medio de las mediciones de software que se utilizan para recolectar los datos
cualitativos y cuantitativos acerca del software y sus procesos para aumentar su calidad.

No se puede mejorar algo no se puede medir, por lo que la medición tiene que ser establecida en
función de proveer valores que permitan estimar desvío y logros alcanzados.

6.1.1 Concepto de Métricas

La medición del software, por lo tanto, se refiere a derivar un valor numérico desde algún atributo
del software o del proceso. Estos valores son comparados con los establecidos por los estándares
de la organización.

Las mediciones de software pueden utilizarse fundamentalmente para cubrir dos objetivos:

 Hacer predicciones generales acerca del sistema, midiendo las características de los
componentes del sistema y reuniéndolas, pudiendo derivar en una estimación general de
alguno de los atributos del sistema, como puede el número de fallos detectados.
 Identificar componentes anómalos, implica encontrar componentes que tengan un
comportamiento fuera de lo normal, normalmente se establece como prioridad la medición
de los componentes de mayor complejidad y criticidad, que se supone pueden tener mayor
cantidad de errores en un funcionamiento.

Si bien todos los estándares de calidad definen la necesidad de hacer mediciones, sólo indican
qué se deben realizar, pero no establecen cómo, cuáles ni dónde aplicarlas, esta es una tarea que
se determina en los lineamientos estratégicos de la organización, quien con la ayuda de los
ingenieros y líderes de proyecto tienen en cuenta las metas de la organización y los objetivos de
las áreas para establecerlas.

Una métrica de software es cualquier tipo de medida relacionada con un sistema, proceso o
documentación de software.

Frecuentemente la medición con lleva una gran controversia y discusión.

1. ¿Cuáles son las métricas apropiadas para el proceso y para el producto?

2. ¿Cómo se deben utilizar los datos que se recopilan?
3. ¿Es bueno usar medidas para comparar gente, procesos o productos?

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 29 -
Estas preguntas surgen cuando se intenta medir algo que no se ha medido en el pasado.

La medición es una actividad muy común el mundo de la ingeniería, normalmente se mide la

potencia de consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos por
mencionar algunos de los tantos aspectos.

Por el contrario, la medición en el mundo de la ingeniería del software se aleja de lo común, se

encuentran dificultades a la hora de ponerse de acuerdo sobre qué medir y cómo van evaluarse
las medidas.

6.1.2 Necesidad de Medir

Como se ha expresado anteriormente, es necesario medir para lograr una mejora en el proceso y
en el producto, existen varias razones para medir un producto:

1. Para indicar la calidad del producto.

2. Para evaluar la productividad de la gente que desarrolla el producto.
3. Par evaluar los beneficios en términos de productividad y de calidad, derivados del uso de
nuevos métodos y herramientas de la ingeniería de software.
4. Para establecer una línea de base para la estimación
5. Para ayudar a justificar el uso de nuevas herramientas o de formación adicional.

Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas y
medidas indirectas.

Medidas Directas. En el proceso de ingeniería se encuentran los valores que identifican el costo,
y el esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución, el tamaño de
memoria y los defectos observados en un determinado período de tiempo.
Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad,
facilidad de mantenimiento, entre otras.

Otra clasificación válida para aplicar a las métricas es que son de ―Control‖ o de ―Predicción‖, ya
que ambas pueden influir en la toma de decisiones de la gestión.

Las métricas de control por lo general están asociadas con los procesos, mientras que las
métricas de predicción se refieren a la complejidad ciclomática de un módulo, la longitud media de
los indicadores de un programa y el número de atributos y operaciones asociadas a un
componente o a un objeto de diseño.

Veamos gráficamente como interactúan estas métricas:

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 30 -
6.1.3 Introducción general de Métricas de Software
Las métricas del software, son las que están relacionadas con el desarrollo del software como
funcionalidad, complejidad y eficiencia.

El proceso de medición del software dentro de un proceso de control de calidad está basado en
los indicadores a tener en cuenta y los componentes a evaluar. Cada uno de los componentes del
sistema se analiza por separado comparando los valores de las métricas entre sí y si se cuenta
con datos históricos, también se comparan con estos.

La retroalimentación puede ser positiva o negativa, en el caso de valores fuera del rango
establecido como normal se utilizan para centrar el esfuerzo de mejora para alcanzar la garantía
de calidad en los componentes que tienen los problemas o fallos.

Los pasos claves en este proceso son:

1. Seleccionar las medidas a realizar, formulando las preguntas que la medición intenta
responder y definir cuáles son las mediciones necesarias para contestar dichas preguntas.
2. Seleccionar los componentes a evaluar, no todos los componentes tienen las mismas
métricas o todas las métricas, por lo que no es conveniente realizar un estándar de medición
para todos los componentes, sino sólo las métricas que sean significativas para cada uno de
ellos.
3. Medir las características de los componentes, una vez seleccionados los componentes
se calculan los valores de las métricas, normalmente se realiza en cuanto a diseño, código y
pruebas, utilizando una herramienta que permita la recogida de datos. Herramientas CASE.
4. Identificar las mediciones anómalas, si se cuenta con una base de datos de mediciones,
se podrá comparar cada resultado obtenido con alguno anterior, observando los valores más
altos y los más bajos de cada métrica, siendo lo óptimo que los valores permanezcan dentro
del rango establecido como de calidad y lo más cercano al límite que le corresponda de
acuerdo a lo que se está midiendo. No todos los indicadores deben aproximarse al máximo
valor o al mínimo, por ejemplo, si medimos el incremento de ventas, se tendrá que aproximar
al máximo valor y si lo supera es una buena noticia, mientras que si medimos la cantidad de

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 31 -
 errores de un software, lo ideal es que se acerque al menor valor o que esté por debajo de
este.
5. Analizar los componentes anómalos, una vez detectados los componentes cuyo
comportamiento está fuera de lo normal, se examinan para decidir si los valores de la
métrica obtenida indica que el comportamiento está en peligro.

Las métricas del software también se pueden clasificar teniendo en cuenta lo que miden y cómo lo
miden, citemos algunas de ellas:

Métricas técnicas: Se centran en las características de software, tales como, la complejidad

lógica, el grado de modularidad. Mide la estructura del sistema, cómo esta hecho.

Métricas de calidad: indican cómo se ajusta el software a los requisitos implícitos y explícitos del
cliente. Es decir cómo se va a medir para que el sistema se adapte a los requisitos que pide el
cliente.

Métricas de productividad. Se centran en el rendimiento del proceso de la ingeniería del

software, es decir, qué tan productivo va a ser el software que se va a diseñar.

Métricas orientadas a las personas. Informan sobre la forma que la gente desarrolla el software
y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. Son las
medidas que se hacen en el proceso de desarrollo en cada etapa, como puede ser horas hombres
estimadas y reales de cada integrante del grupo de desarrollo, en función de la criticidad, tamaño
y complejidad de un componente, un requerimiento o un caso de uso.

Métricas orientas al tamaño. Sirven para determinar el tiempo necesario para terminar el
software y cuantas personas se van a necesitar. Son medidas directas al software y el proceso por
lo que, si una organización de software mantiene registros sencillos, se puede crear una tabla de
datos orientados al tamaño que sirve de referencia futura.

Métricas orientadas a la función. Son medidas indirectas del software y del proceso, se centran
en la funcionalidad o utilidad del programa.
Las métricas orientadas a la función fueron el principio propuestas por Albercht, quien sugirió un
acercamiento a la medida de la productividad denominado método del punto de función. Los
puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas
del dominio de información del software y valoraciones subjetivos de la complejidad del software.

Conclusión y puntos clave a tener en cuenta

Control de la calidad

La gestión de la calidad del software permite señalar si éste tiene escaso número de defectos y se
alcanza los estándares requeridos de mantenibilidad, fiabilidad y portabilidad. Las actividades de
la gestión de la calidad comprenden la planificación de la calidad y el control de la misma,
comprobando que el software está de acuerdo a los estándares definidos.

El control de la calidad significa observar constantemente el 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, realizar una vigilancia permanente a todo el proceso de
desarrollo y ciclo de vida del software.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 32 -
Esta meta puede alcanzarse mediante frecuentes inspecciones a las metodologías de trabajo y
uso de herramientas, revisiones de prototipos y testeo exhaustivo de los productos finales y las
métricas utilizadas.

El manual de calidad organizacional debe documentar un conjunto de procedimientos de garantía

de la calidad. Este documento debe estar basado en algún modelo genérico sugerido por alguna
norma.

Las mejora prácticas están definidas por los estándares de calidad, por lo que es importante
conocerlos e implementar al menos uno de ellos, el que mejor se acomode a la organización. Una
vez implementado hay que respetar los procesos definidos y tomarlo como una cultura de trabajo.

Los equipos de personas encargadas de la revisión de la calidad en el proceso y en la

organización son personas capacitadas para tal fin.

Las mediciones de software se utilizan para obtener datos cuantitativos acerca de las cualidades
medibles del software, sus procesos, sus componentes y del producto final.

No existen métricas de software estandarizadas ni de uso universal.

La calidad de productos software está dada por los procesos que lo desarrollan y no por el
producto mismo. Es el proceso el que ofrece al producto la calidad puesta en la ejecución del
proceso, pero para el cliente y los usuarios finales, la calidad es una característica propia del
producto.

Ante esta visión, la satisfacción del cliente se logra no sólo con un producto que satisfaga las
necesidades del cliente, sino que se deben realizar a conciencia los procesos.

De este modo, la calidad permite definir acciones planeadas y sistemáticas que requieren ser
seguidas para lograr conformidades finales en los procesos de desarrollo, ahorro de costos y
satisfacción de los clientes.

Materia: Ingeniería de Software

Profesora: Lic. Adriana Pérez
- 33 -