Fundamentos de ingeniería de requisitos

Calidad del software.

Competencia.

Comprende la importancia de los estándares, métricas y modelos de madurez

aplicables a proyectos de software de calidad.

M.I.D.S. Angel León Ramos

CONTENIDO
5.1 Definición de calidad. ........................................................................................... 4

5.2. Importancia de la calidad .................................................................................... 5

5.3. Factores de calidad. ............................................................................................ 7

5.4. Aseguramiento de la calidad ............................................................................. 17

5.5 Estándares y métricas de calidad....................................................................... 24

5.6 Modelos de madurez. ......................................................................................... 30

5.6.1 Enfoque de procesos. .................................................................................. 30

5.6.2 PSP y TSP. .................................................................................................. 31

5.6.3 SPICE .......................................................................................................... 35

5.6.4 CMMI. .......................................................................................................... 36

5.6.5 MoProSoft. ................................................................................................... 37

Cuadro comparativo ............................................................................................. 38

Los Sistemas de Software son cada vez más importantes en la sociedad actual y
crecen rápidamente en tamaño y complejidad. Desarrollar Software de Calidad,
basado en estándares con funcionalidad y rendimiento ajustado a las necesidades y
exigencias del cliente, son aspectos fundamentales para asegurar el éxito del
producto software.

5.1 Definición de calidad.

Ishikawa define calidad como "Desarrollar, diseñar, manufacturar y mantener un

producto de calidad que sea el más económico, el útil y siempre satisfactorio para el
consumidor". (Ishikawa, 1986)

El software se puede definir como un conjunto de programas intangibles encargados

de recibir órdenes, procesar datos y reflejar resultados, estas son características que
hacen que el software sea muy demandado pues facilita, complementa o automatiza
tareas y procesos que se llevan a cabo en el día a día de los diferentes hogares y
organizaciones.

La calidad en el software está en relación directa con el cumplimiento de los

requerimientos formulados por el usuario, de tal forma que, si un programa no cumple
con alguno de estos requerimientos, es un software de baja calidad. Aunque el criterio
de cumplimiento de los requerimientos es un factor importante, no es el único, ya que
existen condiciones implícitas que el software debe cumplir como son eficiencia,
seguridad, integridad, consistencia, entre otras.

Un software es de alta calidad cuando cumple con los requerimientos del usuario, si:

– Es eficiente al utilizar los recursos de la máquina (programas muy lentos).

– Es confiable; los resultados que entrega varían, no son siempre iguales al procesar
los mismos datos.

– Es fácil de utilizar.
– Es seguro.

– Es fácil hacerle mantenimiento. ¿?

5.2. Importancia de la calidad.

La importancia radica principalmente en entregar productos de calidad esperada, en

donde se previenen riesgos a futuro. Así mismo, todo software puede tener fallos que
terminen siendo responsables de grandes pérdidas de dinero para la empresa. Cabe
resaltar que mientras más tarde se detecten los defectos o errores, mayores pueden
ser las consecuencias.

Conocer cada uno de los indicadores del proceso de la calidad del software y cómo
se está desempeñando su producto, es indispensable para brindar soluciones claras
a las necesidades de los usuarios, desde un aspecto fácil de manejar y que sea
cómodo. El objetivo, es que logre soportar todos los requerimientos, sea amigable,
seguro, útil, usable, estable y satisfaga las necesidades y requerimientos del usuario
sin que presente fallos o errores.

Dado que las pruebas de calidad de software revisan, supervisan y examinan la forma
en que se desenvuelve el producto, es posible contar con un informe final en el que
se establece si el software cumple o no con lo que espera el usuario, según el
motivo por el cual fue hecho. A la vez que se comprueba la exactitud y confiabilidad
de los procesos apoyados en cada una de las pruebas realizadas: funcionales y no
funcionales.

Errores que se cometen, al no contar con la implementación de calidad de software.

A pesar de que existen diversas causas que pueden afectar la calidad de un software,
es indispensable hacer conciencia sobre los resultados de los errores que se cometen
al no contar con un control de calidad, ya que existe una amplia probabilidad de que
se presenten un sin número de problemas en el uso del sistema, haciendo que se
perjudique visiblemente la imagen de la empresa, perdiendo clientes potenciales y
costos visibles e invisibles que desfavorece a las organizaciones.
➢ No contar con gestión de pruebas.
Al no contar con un plan de pruebas, no tener casos de pruebas o datos y solo
mirar la funcionalidad del software de manera superficial, hará que obtenga
altos índices de incidencias y como consecuencia, una mala gestión. Esto,
puede hacer que nadie use el sistema y que la inversión realizada no sirva,
ocasionando a su vez costos adicionales de corrección y modificación en el
sistema para arreglar los fallos.

➢ Deficiencia en la gestión de datos de prueba.

Es fundamental definir y gestionar datos previamente para identificar las
características necesarias para abarcar todas las pruebas posibles. Si no se
gestiona correctamente los datos de prueba, puede significar que no se
prueben todos los escenarios posibles, ya que la información recopilada es la
base para poder realizar estas pruebas de forma correcta.

➢ Subestimar la planificación y la complejidad del software.

La complejidad de un proyecto, en ocasiones, es el principal obstáculo para
dar inicio a su desarrollo. No contar con una planeación estratégica y
verificación en cada etapa, de forma preventiva es muy posible el hecho de
que contenga errores que hubieran podido haber sido detectados antes.

➢ No automatizar las pruebas.

La automatización de pruebas, es una práctica idónea que permite optimizar el
tiempo de ejecución en las distintas etapas del desarrollo de software.
Adicionalmente permite realizar una cobertura mayor, cuando se agregan las
pruebas técnicas, como carga, volumen, stress. Lo que hace, que este sea
progresivo y funcional de acuerdo a las necesidades de cada empresa. La
automatización de pruebas brinda eficiencia en la identificación de fallas,
reduciendo las probabilidades de errores humanos, entre otros beneficios.
Aunque hay algunas pruebas que se realizan de forma manual, como las
 pruebas de usabilidad y aceptación se recomienda que las regresiones de gran
volumen sean siempre automatizadas para garantizar la calidad de software.

5.3. Factores de calidad.

Es el grado con el que un sistema, componente o proceso cumple los requerimientos

especificados y las necesidades o expectativas del cliente o usuario.

Factores que determinan la calidad del software:

Se pueden clasificar en dos grandes grupos (Pressman, 2010):

• Medidas Directas: La medida o medición decimos que es directa, cuando

disponemos de un instrumento de medida que nos muestra un resultado
(generalmente numérico).
• Medidas Indirectas: Cuando hablamos de sistemas informáticos no siempre es
posible realizar una medida directa, porque no disponemos del instrumento
adecuado que nos permita realizar esa medición.

Métricas del software.

Son las que están relacionadas con el desarrollo del software como funcionalidad,
complejidad, eficiencia.

Entre las métricas del software tenemos las siguientes:

1. Métricas técnicas: Se centran en las características del software. Aquí

medimos la complejidad lógica y el grado de modularidad del sistema. Mide la
estructura del sistema, el cómo está hecho.

2. Métricas de calidad: Son todas las métricas de software que definen de una u
otra forma la calidad del software; tales como corrección, exactitud, integridad,
facilidad de uso, estructuración o modularidad, pruebas, facilidad de
mantenimiento, reusabilidad, cohesión del módulo, acoplamiento del módulo,
 etc. Estas son los puntos críticos en el diseño, codificación, pruebas y
mantenimiento.

Proporcionan una indicación de 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 solicita el cliente.

Corrección: es el grado en que el software desempeña la función para la que fue

creado y se mide en defectos por KLDC (miles de líneas de código).

Facilidad de Mantenimiento: es la sencillez con que un programa puede corregirse si

se encuentra un error, al adaptarse si su entorno cambio o mejorar si el cliente cambia
los requisitos y se mide en forma indirecta en TMC (Tiempo Medio de Cambio)

Integridad: es la habilidad de un sistema para resistir ataques que requiere la

definición de amenaza y seguridad y se calcula: integridad = 1 – (amenaza * (1 –
seguridad)).

Por ejemplo, dados los siguientes valores de un paquete de base de datos en dos
proyectos, podemos calcular la integridad.

Integridad para el proyecto 1:

Integridad = 1 – 0.7 * (1 – 0) = 0.3

Integridad para el proyecto 2:

Integridad = 1 – 0.2 * (1 - 0.8) = 0.96

Si la amenaza (probabilidad de que un ataque ocurrirá) es 0.25, y la seguridad

(posibilidad de repeler un ataque) es 0.95, la integridad del sistema es 0.99 (muy
elevada).
Integridad=1-0.25*(1-0.95)=0.99

Si, por otra parte, la probabilidad de amenaza fuera 0.5 y la posibilidad de repeler un
ataque es solo 0.25, la integridad del sistema es 0.63 (inaceptablemente baja).

Facilidad de uso: es el intento por cuantificar la sencillez de una aplicación al utilizarla.

3. 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 él. Se refiere a las
características del software.
4. Métricas de costo: se centra en el costo total del sistema informático.

5. Métricas orientadas al tamaño: Esta nos permite conocer el tiempo en el que

se terminará el software y cuántas personas se necesitan para su desarrollo,
aquí se mide las variables con las que desarrollamos el software.

Si una organización de software mantiene registros sencillos, se puede crear una

tabla de datos orientados al tamaño, como la que muestra la figura, que lista cada
proyecto de desarrollo de software y las medidas correspondientes de cada proyecto.
Refiriéndonos a la entrada de la figura del proyecto alfa: se desarrollaron 12,100
líneas de código (LDC) con 24 personas/mes y con un costo de $168,000 pesos. Debe
tenerse en cuenta que el esfuerzo y el costo registrados en la tabla incluyen todas las
actividades de ingeniería del software (análisis, diseño, codificación y prueba) y no
sólo la codificación. Otra información sobre el proyecto alfa indica que se
desarrollaron 365 páginas de documentación, se registraron 134 errores antes de que
el software se entregara al cliente y se encontraron 29 errores después de
entregárselo al cliente dentro del primer año de utilización.

También se observa que trabajaron tres personas en el desarrollo del proyecto alfa.

LDC: Número de líneas de código.

Esfuerzo: Número de horas invertidas en la realización del sistema.
$(000): Costo total del sistema informático
Pp.doc.: El número de páginas de los manuales de documentación del sistema.
Errores: Errores detectados antes de la entrega del sistema.
Defectos: Errores detectados después de la entrega del sistema.
Personas: Personal que realizó el proyecto.

Con los datos registrados durante la elaboración del proyecto se puede generar al
final del proyecto el siguiente conjunto de métricas:

❖ Productividad = KLDC /Esfuerzo

❖ Calidad = Errores / LDC
❖ Documentación = Pp.doc./LDC
❖ Costo = $(000)/LDC

6. Métricas orientadas a la función o puntos de función:

Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar
de calcular las líneas de código LDC, las métricas de función se centran en la
funcionalidad o utilidad del programa. Los puntos de función nos indican la medida de
la productividad.
Los puntos de función se obtienen utilizando una función empírica basado en medidas
cuantitativas del dominio de información del software y valoraciones subjetivas de la
complejidad del software.

Se calculan los puntos de función en base a la siguiente tabla:

Valor con peso de complejidad = Suma del número de apariciones del elemento i (por
ejemplo, salidas) para cada nivel de complejidad (bajo, medio, alto).

Se determinan 5 características del ámbito de la información y los cálculos aparecen

en la posición apropiada de la tabla. Los valores del ámbito de información están
definidos de la siguiente manera:
I. Números de entradas de usuario: se cuenta cada entrada del usuario que
proporcione al software diferentes datos orientados a la aplicación. Las
entradas deben ser distinguidas de las peticiones que se contabilizan por
 separado. El flujo de datos deberá tener una sola dirección, del exterior al
interior. Como consecuencia de una entrada siempre deberá actualizarse un
archivo lógico interno. Ej. Pantallas de entrada de datos, lector de códigos de
barras, lector de tarjetas magnéticas y electrónicas, captura de imágenes, voz,
etc.

Clasificación de las entradas:

II. Número de salidas del usuario: se encuentra cada salida que proporciona al
usuario información orientada a la aplicación. En este contexto las salidas se
refieren a informes, pantallas de salida de datos, grabación de bandas
magnéticas, listados, mensajes de error, Transferencia de datos a otras
aplicaciones, ya sea mediante archivos o transmisión de datos. Los elementos
de datos individuales dentro de un informe se encuentran por separado. Son
todos aquellos procesos que hacen llegar datos desde la aplicación hacia el
exterior, a un usuario o a otra aplicación. El flujo de datos deberá tener una
sola dirección, del interior al exterior.
Clasificación de las salidas:
III. Números de consultas al usuario: una petición o consulta está definida como
una entrada interactiva que resulta de la generación de algún tipo de respuesta
en forma de salida interactiva (en línea). Se cuenta cada petición por separado.
Son todos aquellos procesos que están formados por una combinación de
entradas y salidas, produciendo una consulta a los datos. El flujo de datos
deberá tener dos direcciones. Como consecuencia de una consulta no se
modifican los datos del sistema. (Igual a tabla de entradas)

IV. Numero de archivos lógicos internos: Es un grupo de datos relacionados,

tal como los percibe el usuario y que son mantenidos por la aplicación. Se
cuenta cada archivo maestro lógico, o sea una agrupación lógica de datos que
puede ser una parte en una gran base de datos o un archivo independiente.
Los archivos se cuentan una sola vez, independientemente del número de
procesos que los acceden. Ejemplos: Clientes, Socios, Artículos, Proveedores.
Clasificación de los archivos lógicos internos:

V. Número de interfaces externas: agrupamiento lógico de datos que

reside fuera de la aplicación, pero que proporciona información que puede usar
la aplicación. Se cuentan todas las interfaces legibles por la máquina, por
ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir
información a otro sistema. Son archivos internos de otra aplicación.
Clasificación de los archivos de interfaz:
En base a las tablas anteriores, se coloca el número de elementos de las
características del sistema en el peso correspondiente a la tabla de valores de pesos
y puntos de función sin ajustar.

Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a
cada cuenta. Las organizaciones que utilizan métodos de puntos de función
desarrollan criterios para determinar si una entrada es denominada simple, media o
compleja. No obstante, la determinación de la complejidad es algo subjetivo.

Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a
cada cuenta. Las organizaciones que utilizan métodos de puntos de función
desarrollan criterios para determinar si una entrada es denominada simple, media o
compleja. No obstante la determinación de la complejidad es algo subjetivo.
Para calcular los puntos de función se utiliza la siguiente relación.

PFA = Puntos de Función Ajustados = ΣPFSA * [0.65 + 0.01 * Σ(fi)]

Donde PFSA es la suma de todas las entradas de puntos de función sin ajustar
obtenidas de la tabla anterior.

Los valores 0.65 y 0.01 son valores establecidos obtenidos a partir de datos
procedentes de diferentes proyectos referentes al nivel de error producidos en un
promedio de 5000 proyectos.

Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados
en las respuestas a las cuestiones señaladas en la siguiente tabla (Tabla 4).

Fi = total de factores de corrección.

Los valores constantes de la ecuación anterior y los factores de peso aplicados en las
encuestas de los ámbitos de información han sido determinados empíricamente.
Evaluar cada factor de complejidad en escala 0 a 5.

Se le asigna una puntuación a cada factor de corrección FC:

5.4. Aseguramiento de la calidad.
(Aplicar estos criterios a su proyecto, un equipo diferente debe realizar las
actividades en el proyecto de otro equipo)
La garantía de calidad en el software comienza realmente con la aplicación de una
metodología formal para enfrentar las etapas de análisis y diseño del sistema a
construir. Posteriormente a la creación de la especificación del sistema o prototipo, se
debe garantizar su calidad.

La actividad que permite garantizar la calidad es la revisión técnica formal realizada

por el grupo de control de calidad. Los objetivos de dicha revisión son:

1) Descubrir errores en la función, la lógica o la implementación de cualquier

representación del software.

2) Verificar que el software bajo revisión cumpla los requerimientos.

3) Garantizar que el software ha seguido los lineamientos predefinidos.

4) Conseguir un software que sea desarrollado en forma uniforme.

Conseguir software de calidad es algo muy complejo que implica tanto una alta
calificación de los profesionales encargados del desarrollo como de la existencia de
procesos en la empresa que realiza el software, de una gestión integral de la calidad
desde el inicio del producto hasta el mantenimiento del mismo, siempre teniendo claro
que la calidad del software NO es negociable, porque al final lo que importa es la
satisfacción de los clientes.
Las herramientas, en la propuesta metodológica de aseguramiento de la calidad del
software, son un conjunto de técnicas y artefactos que ayudan a mantener el control
y a la vez administrar la calidad en el desarrollo desde el inicio hasta el final, de un
producto de software. A continuación, se describirán y mostrarán las herramientas que
propone este método de ACS.

Tabla de Control de Riesgo

La Figura 1 muestra es un control de riesgo, que tiene como objetivo identificar,

controlar y eliminar las fuentes de riesgo antes de que empiecen a afectar el
cumplimiento de los objetivos del proyecto. De esta manera se pueden evaluar y
estimar el impacto de los riesgos posibles y a su vez establecer un plan de
contingencia para mitigarlos en el caso de que el problema se presente, teniendo
como objetivo la pro actividad. Por lo tanto:
1) Se inicia antes del trabajo técnico.
2) Se categoriza o clasifica según su impacto.
3) Identifica los riesgos potenciales, valorando su probabilidad de impacto.
4) Establecer un plan.

Figura 1. Tabla de control de riesgos.

Historial de Cambio

En la Figura 2 se muestra el Documento Historial de Cambio, que permite al equipo

de trabajo llevar un registro de los cambios o mejoras solicitadas en el Documento de
Petición de Mejora, junto con ello también admite llevar un control de los documentos
o entregables, tanto sus versiones como alguna modificación en ellos.

Figura 2. Historial de cambio.

Documento de Petición de Mejora

Este documento llamado Petición de Mejora, que se puede observar en la Figura 3,

tiene como objetivo priorizar y mostrar las modificaciones que proponen o
recomiendan los Stakeholders o Clientes. De esta manera, se podrán analizar dichos
cambios o propuestas e implementarlas en el proyecto, controlando de modo
ordenado los cambios en el desarrollo del sistema. Cabe destacar que este
documento sirve para gestionar cambios o mejoras ya sea en los requisitos del
sistema, entregables, artefactos o documentación del proyecto, luego de ser testeada
o implementado.

Figura 3. Documento de petición de mejora.

Adecuación de requisitos (Repertory Grid)

Uno de los problemas fundamentales en el desarrollo de software es la mala calidad

de la educción (La educción es una actividad dentro del proceso de la Ingeniería de
Requisitos que recupera información relevante acerca del dominio del problema y de
las necesidades de los clientes para la conformación de los requisitos del producto
software), provocando costos importantes en los proyectos. Por lo tanto, para evitar
los problemas anteriores y desarrollar productos que satisfagan al cliente, se propone
utilizar el emparrillado (Repertory Grid) planteada en la Figura 4 muestra un ejemplo
de Repertory Grid, la cual permite determinar el valor de adecuación de dichos
requisitos a las necesidades del usuario, a mayor adecuación, mayor calidad.

Para conocer el repertorio de constructos mediante el cual las personas construyen

su entorno, (B. Gonzalez-Baixauli, 2007). González menciona una técnica conocida
como “test de repertorios de constructos de roles” (Rep-Test, Test de la Rejilla,
Repertory Grid o grilla). La cual resulta práctica, ya que permite relacionar constructos
con elementos por medio de una matriz o grilla y obtener nuevo conocimiento, crear
reglas entre constructos, o determinar similitud entre ellos. Aplicando la técnica del
Repertory Grid a IR-SixSigma se obtienen niveles de similitud (adecuación) que
relacionan constructos con los requisitos elicitados. Por tanto, lo primero que se debe
hacer es determinar que conceptos se van a utilizar como constructos, recordando
que aquello que se quiera relacionar debe ser considerado un constructo, puesto que
lo que se va a obtener son relaciones entre constructos, así como el valor de
adecuación de un requisito determinado con dicho constructo.

Si se considera que un requisito de calidad se debe ajustar a lo que establece el

estándar IEEE 830, y que su valor de adecuación a las necesidades del usuario
depende directamente del grado de cumplimiento a lo establecido en dicho estándar.

Los constructos corresponderán de esta forma a las características establecidas en

el estándar IEEE 830, tales como Correcto/Incorrecto, Inequívoco/Ambiguo,
Consistente/Débil, etc.
Por lo anterior el polo nominal o de semejanza de los constructos dicotómicos a utilizar,
se estructura de la siguiente forma:

❖ Correcto, si, y sólo si, cada requisito declarado se encuentra en el producto.

❖ Inequívoco, si, y sólo si, cada requisito declarado tiene sólo una interpretación.
Debe ser inequívoco. Para aquellos que lo crean y para aquellos que lo usan
❖ Completo, si, y sólo si, están relacionados con la funcionalidad, el desarrollo,
las restricciones de diseño, los atributos y las interfaces externas.
❖ Consistente, si, y sólo si, ningún subconjunto de requisitos individuales genero
conflicto en él.
❖ Importante, si, y sólo si, él tiene un identificador para indicar la importancia que
lo relaciona al producto (esencial o deseable).
❖ Estable, si, y sólo si, el número de cambios realizados o que se espera realizar
es mínimo.
❖ Comprobable, si, y sólo si, allí existe algún proceso rentable finito con que una
persona o la máquina puede verificar que el producto reúne el requisito.
❖ Modificable, si, y sólo si, su estructura y estilo son tales que puede hacerse
cualquier cambio fácilmente, completamente y de forma consistente
conservando la estructura y estilo.
❖ Identificable, si, y sólo si su origen está claro y facilita sus referencias en el
desarrollo futuro o documentación del mismo, debiendo ser tanto Identificable
Dirigido Hacia Atrás, como Identificable Dirigido Hacia Adelante.
Por otro lado, el polo de contraste estará compuesto por: Incorrecto, Ambiguo,
Incompleto, Débil, Intrascendente, Inestable, No Comprobable, No Cambiable, No
Reconocible.

Los constructos a utilizar serán del tipo multivaluados (1-9) en donde 9 es la máxima
aproximación al polo nominal y por su parte 1 su homologo al polo de contraste. De
esta forma se obtendrán los niveles de adecuación que poseen cada uno de los
requisitos elicitados: Verde (7-9), Naranja (4-6) y Rojo (1-3).

Tabla 1. Ejemplo de Aplicación de IR-SIXSIGMA.

5.5 Estándares y métricas de calidad.

Los estándares de calidad de software hacen parte de la ingeniería de software,

utilización de estándares y metodologías para el diseño, programación, prueba y
análisis del software desarrollado, con el objetivo de ofrecer una mayor confiabilidad,
mantenibilidad en concordancia con los requisitos exigidos, con esto se eleva la
productividad y el control en la calidad de software, parte de la gestión de la calidad
se establecen a mejorar su eficacia y eficiencia.

NORMAS ISO/IEC
ISO 12207 – Modelos de Ciclos de Vida del Software.
Estándar para los procesos de ciclo de vida del software de la organización, Este
estándar se concibió para aquellos interesados en adquisición de software, así como
desarrolladores y proveedores. El estándar indica una serie de procesos desde la
recopilación de requisitos hasta la culminación del software.

El estándar comprende 17 procesos lo cuales son agrupados en tres categorías:

Principales
De apoyo
De organización
Este estándar agrupa las actividades que se pueden llevar a cabo durante el ciclo de
vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro
procesos organizativos.
Norma ISO/IEC 9126
La norma ISO/IEC 9126 de 1991, es la norma para evaluar los productos de software,
esta norma indica las características de la calidad y los lineamientos para su uso, las
características de calidad y sus métricas asociadas, pueden ser útiles tanto como para
evaluar el producto como para definir los requerimientos de la calidad y otros usos.
Esta norma definida por un marco conceptual basado en los factores tales como
Calidad del Proceso, Calidad del Producto del Software y Calidad en Uso; según el
marco conceptual, la calidad del producto, a su vez, contribuye a mejorar la calidad
en uso.
La norma ISO/IEC 9126 define la calidad en uso como la perspectiva del usuario de
la calidad del producto software cuando éste es usado en un ambiente específico y
un contexto de uso específico. Éste mide la extensión para la cual los usuarios pueden
conseguir sus metas en un ambiente particular, en vez de medir las propiedades del
software en sí mismo.

El modelo de la calidad en uso muestra un conjunto de 4 características: efectividad,

productividad, integridad, y satisfacción.

Estándar ISO/IEC 14598

El estándar ISO/IEC 14598 es actualmente usado como base metodológica para la
evaluación del producto software. En sus diferentes etapas, establece un marco de
trabajo para evaluar la calidad de los productos de software proporcionando, además,
métricas y requisitos para los procesos de evaluación de los mismos.

La norma define las principales características del proceso de evaluación

Repetitividad.
Reproducibilidad.
Imparcialidad.
Objetividad.
Para estas características se describen las medidas concretas que participan:

Análisis de los requisitos de evaluación.

Evaluación de las especificaciones.
Evaluación del diseño y definición del plan de evaluación.
Ejecución del plan de evaluación.
Evaluación de la conclusión.
El estándar ISO/IEC 14598 define el proceso para evaluar un producto de
software, el mismo consta de seis partes:

1. ISO/IEC 14598-1 Visión General: provee una visión general de las otras cinco
partes y explica la relación entre la evaluación del producto software y el
modelo de calidad definido en la ISO/IEC 9126.
2. ISO/IEC 14598-2 Planeamiento y Gestión: contiene requisitos y guías para las
funciones de soporte tales como la planificación y gestión de la evaluación del
producto del software.

3. ISO/IEC 14598-3 Proceso para desenvolvedores: provee los requisitos y guías

para la evaluación del producto software cuando la evaluación es llevada a
cabo en paralelo con el desarrollo por parte del desarrollador.

4. ISO/IEC 14598-4 Proceso para adquirentes: provee los requisitos y guías para
que la evaluación del producto software sea llevada a cabo en función a los
compradores que planean adquirir o reutilizar un producto de software
existente o pre-desarrollado.

5. ISO/IEC 14598-5 Proceso para avaladores: provee los requisitos y guías para
la evaluación del producto software cuando la evaluación es llevada a cabo por
evaluadores independientes.

6. ISO/IEC 14598-6 Documentación de Módulos: provee las guías para la

documentación del módulo de evaluación.
Norma ISO/IEC 25000 (SquaRE)
ISO 25000:2005 (SQuaRE -Software Quality Requirements and Evaluation) es una
nueva serie de normas que se basa en ISO 9126 y en ISO 14598 (Evaluación del
software). Uno de los principales objetivos de la serie SQuaRE es la coordinación y
armonización del contenido de ISO 9126 y de ISO 15939:2002 (Measurement
Information Model).

ISO 15939 tiene un modelo de información que ayuda a determinar que se debe
especificar durante la planificación, performance y evaluación de la medición. Para su
aplicación, cuenta con los siguientes pasos: Recopilar los datos, Preparación de los
datos y Análisis de los datos.

SQuaRE está formada por las divisiones siguientes:

1. ISO/IEC 2500n. División de gestión de calidad. Los estándares que forman

esta división definen todos los modelos comunes, términos y referencias a los
que se alude en las demás divisiones de SQuaRE.
2. ISO/IEC 2501n. División del modelo de calidad. El estándar que conforma esta
división presenta un modelo de calidad detallado, incluyendo características
para la calidad interna, externa y en uso.
3. ISO/IEC 2502n. División de mediciones de calidad. Los estándares
pertenecientes a esta división incluyen un modelo de referencia de calidad del
producto software, definiciones matemáticas de las métricas de calidad y una
guía práctica para su aplicación.
4. ISO/IEC 2503n. División de requisitos de calidad. Los estándares que forman
parte de esta división ayudan a especificar los requisitos de calidad. Estos
requisitos pueden ser usados en el proceso de especificación de requisitos de
calidad para un producto software que va a ser desarrollado ó como entrada
para un proceso de evaluación. El proceso de definición de requisitos se guía
por el establecido en la norma ISO/IEC 15288 (ISO, 2003).
5. ISO/IEC 2504n. División de evaluación de la calidad. Estos estándares
proporcionan requisitos, recomendaciones y guías para la evaluación de un
 producto software, tanto si la llevan a cabo evaluadores, como clientes o
desarrolladores.
6. ISO/IEC 25050–25099. Estándares de extensión SQuaRE. Incluyen requisitos
para la calidad de productos de software «Off-The-Self» y para el formato
común de la industria (CIF) para informes de usabilidad.
5.6 Modelos de madurez.
5.6.1 Enfoque de procesos.
La planificación de la calidad es el proceso en el cual se desarrolla un plan de calidad
para un proyecto. El plan de calidad define la calidad del software deseado y describe
cómo valorar ésta. Por lo tanto, define lo que es software de «alta calidad». Sin esta
definición, los diferentes ingenieros pueden trabajar en direcciones opuestas para
optimizar los atributos de proyecto.

El plan de calidad selecciona los estándares organizacionales apropiados para un

producto y un proceso de desarrollo particulares. Esta estructura comprende:
1. Introducción del producto. Descripción del producto, el mercado al que se dirige
y las expectativas de calidad.
2. Planes de producto. Contiene las fechas de terminación del producto y las
responsabilidades importantes junto con los planes para la distribución y el
servicio.
3. Descripciones del proceso. Contiene los procesos de desarrollo y de servicio
a utilizar para el desarrollo y administración del producto.
4. Metas de calidad. Contiene las metas y planes de calidad para el producto.
Incluyendo la identificación y justificación de los atributos de calidad
importantes del producto.
5. Riesgos y gestión de riesgos. Contiene los riesgos clave que podrían afectar a
la calidad del producto y las acciones para abordar estos riesgos.

Los planes de calidad obviamente difieren dependiendo del tamaño y del tipo de
sistema que se desarrolle. Existe una amplia variedad de atributos de calidad del
softwares potenciales a considerar en el proceso de planificación de la calidad. Ver
atributos de calidad en la figura siguiente.
El control de la calidad implica vigilar el proceso de desarrollo de software para
asegurar que se siguen los procedimientos y los estándares de garantía de calidad.
En el proceso de control de calidad del proyecto se comprueba que las entregas
cumplan los estándares definidos.

5.6.2 PSP y TSP.

El personal Software Process, conocido por sus siglas como PSP, es una metodología
de reciente creación, proveniente del Instituto de Ingeniería del Software. PSP es una
alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la forma en
la que construyen software. Considerando aspectos como la planeación, calidad,
estimación de costos y productividad. PSP es una metodología que vale la pena
revisar cuando el ingeniero de software está interesado en aumentar la calidad de los
productos de software que desarrolla dentro de un contexto de trabajo individual.

Características
En PSP todas las tareas y actividades que el ingeniero de software debe realizar
durante el proceso de desarrollo de un producto de software, están puntualmente
definidas en un conjunto de documentos conocidos como scripts. Los scripts son el
punto medular en PSP, por lo que hace mucho énfasis en que deban ser guiados en
forma disciplinada, ya que de ello dependerá el éxito de la mejora que se busca. Gran
parte de las tareas y actividades definidas en los scripts generará en su realización
un conjunto de datos, fundamentalmente de carácter estadístico.
La aplicación de PSP en varios procesos de desarrollo, y el análisis de la información
estadística generada e cada uno de éstos, permitirán al ingeniero de software
identificar, tanto sus fortalezas como sus debilidades, y crecer a través de un proceso
de autoaprendizaje y auto mejora.
La calidad de PSP, es u aspecto fuertemente relacionado con la cantidad de defectos
que el producto de software contiene.

En este nivel se introducen algunos métodos aplicables al proceso de desarrollo de

software, dentro de un enfoque de proyectos a gran escala pero sin lidiar con
problemas de comunicación y coordinación de los equipos de trabajo.
Pasos a seguir
Los scripts se organizan en cuatro niveles, identificados del 0 al 3, atendiéndose en
cada nivel un conjunto de aspectos a mejorar del proceso de desarrollo de software.
Al primer nivel se le conoce como 0 o medición personal, al segundo como nivel1 o
de planeación personal, al tercero, como nivel2 o de calidad personal y al cuarto como
nivel3 o cíclico personal.

Cada uno de estos niveles, con excepción del 3, tiene una versión que los extiende,
introduciendo tareas y actividades para un mejor manejo de los aspectos de interés
en nivel, o bien para incluir nuevos aspectos.

Cada uno de los niveles extiende los aspectos considerados en el nivel inmediato
anterior. Una de las razones de esta clasificación puede ser que el PSP es una
metodología de mejora basada en datos estadísticos, los cuales deben ser
cuidadosamente recabados por el ingeniero de software; el aumento gradual de la
cantidad de datos que debe recolectar el ingeniero introduce, por consiguiente, el
cambio en su manera de trabajo de una manera paulatina. Se recomienda un uso
incremental de PSP, iniciando con el nivel más bajo durante un primer proyecto de
desarrollo y, en proyectos siguientes, ascendiendo a niveles superiores. Los scripts
no pueden utilizarse en forma separada o desordenada.

PSP es una alternativa, de las muchas que han surgido recientemente, para mejorar
el proceso de desarrollo de software. Más que clasificar un conjunto de sentencias
como ventajas y desventajas, a continuación, se citan algunas:

PSP es una metodología basada en estimación. La estimación permite saber cuándo

y cómo se desarrollan las tareas de un proceso, por lo que podría citarse como un
aspecto importante de esta metodología el estar basada en métricas y estimaciones.

La información de las métricas y estimaciones se utiliza para evaluar y mejorar

procesos frutos. PSP parte de la premisa que, si el ingeniero de software conoce sus
fortalezas y debilidades, puede establecer las acciones necesarias para erradicar o
explotar los aspectos identificados en la forma en que desarrolla software.
Aunque lo mencionado en el punto anterior podría sonar bastante atractivo, la forma
de llegar a ese auto conocimiento puede resultar tediosa, y en el peor de los casos,
una pesadilla para el desarrollador. Salvo muy pocas excepciones, los ingenieros de
software nunca realizan procedimientos formales.

La importancia del entrenamiento y el marco de trabajo personal del PSP es que

provee a los ingenieros un proceso disciplinado, métricas de desempeño, habilidades
de planeación y estimación y habilidades de administración de la calidad.

El PSP se desarrolló considerando los siguientes principios de calidad y planeación:

❖ Cada ingeniero debe planear su trabajo con base en sus datos históricos
personales.
❖ Los ingenieros deben medir su trabajo y analizar los resultados para mejorar
su desempeño.
❖ Los ingenieros deben sentirse personalmente responsables de la calidad de
sus productos buscando decididamente hacer trabajo de calidad.
❖ Es más eficiente prevenir los defectos que encontrarlos y corregirlos.
❖ La manera correcta es siempre la manera más rápida y económica de hacer el
trabajo.

Team Software Process (TSP)

En combinación con el Personal Software Process (PSP), el llamado Team Software
Process (TSP) proporciona un marco de trabajo de procesos definidos que está
diseñado para ayudarle a equipos de gerentes e ingenieros a organizar y producir
proyectos de software de gran escala, que tengan tamaños mayores a varios miles
de líneas de código. El objetivo del TSP es mejorar los niveles de calidad y
productividad de un proyecto de desarrollo de software de un equipo, con el fin de
ayudarlos a alcanzar los acuerdos de costos y tiempos en dicho desarrollo.

La versión inicial del TSP fue desarrollada por Watts Humphrey en 1996, y el primer
Reporte Técnico para TSP fue publicado en el año 2000, patrocinado por el
Departamento de Defensa de los Estados Unidos. El Libro de Watts Humphrey
llamado "Introduction to the Team Software Process" (Addison Wesley Professional,
Massachusetts, 1999), presenta el TSP en detalle y se enfoca en el proceso de la
construcción de un equipo productor de software, estableciendo objetivos del equipo,
distribuyendo los roles, y otras actividades de trabajo en equipo.

Funcionamiento
Antes que los ingenieros de software puedan participar en el TSP, se requiere que ya
hayan aprendido sobre el Personal Software Process (Personal Software Process),
de manera tal que el TSP pueda funcionar de manera adecuada. El TSP comienza
con un proceso de cuatro días llamado despegue. El despegue está diseñado para
comenzar el proceso de construcción de los equipos y durante éste tiempo, los
equipos y sus administradores establecen metas, definen roles, evalúan riesgos y
producen un plan de equipo. El despegue generalmente se hace con un coach
específicamente entrenado, o con un líder que ya ha gerenciado varios proyectos que
han usado TSP para su desarrollo.

El TSP es un proceso diseñado para equipos de software auto-dirigidos y de alto

desempeño, ayudándolos a planear su trabajo, negociar compromisos con la gerencia,
dar seguimiento cabal a sus compromisos y producir productos de calidad mientras
mejoran su rendimiento. El marco de trabajo de TSP incluye roles, plantillas, procesos,
guías, especificaciones y listas de chequeo.

Características TSP
➢ Usa equipos auto-dirigidos con base en el estilo de administración de Peter
Drucker (administración del conocimiento) junto con un coach que ayuda a
desarrollar las habilidades de trabajo en equipo en los individuos.
➢ Tiene procesos operacionales flexibles que permiten a los equipos adaptar los
procesos, contando además con un marco de trabajo de métricas que soporta
a su proceso e incluye técnicas para la administración de la calidad usando
revisiones personales, inspecciones e índices de desempeño de la calidad.
➢ Usa planes detallados con actividades no mayores a 10 hrs en periodos de 3-
6 meses y establece juntas de cierre (postmortems) para finales de ciclo o de
proyecto.
 ➢ Utiliza lanzamientos de proyectos de 3.5 días para planear las actividades y
para integrar a los miembros del equipo.
➢ Cada miembro tiene asignado roles, metas y riesgos del proyecto.
➢ Los calendarios del equipo son desglosados en calendarios personales que
son ajustados con base en datos personales.

5.6.3 SPICE
Es un estándar importante iniciativa internacional para apoyar el desarrollo de una
Norma Internacional para la Evaluación de Procesos de Software. El proyecto tiene
tres objetivos principales: Para desarrollar un proyecto de trabajo para un estándar
para la evaluación de procesos de software. Para llevar a cabo los ensayos de la
industria de la norma emergente. Para promover la transferencia de tecnología de la
evaluación de procesos de software en la industria mundial del software a nivel
mundial.

El estándar SPICE creciente en número de métodos de evaluación disponibles, y la

creciente utilización de la técnica comercial en áreas sensibles, fueron los factores
clave que impulsaron el desarrollo y la aceptación de una propuesta para desarrollar
un estándar internacional para la evaluación de procesos de software.
Una Norma Internacional sobre Evaluación de Procesos de Software ofrecerá los
siguientes beneficios a la industria y los usuarios del software: beneficios para la
Industria del Software Los proveedores de software se someterá a un solo esquema
de proceso de evaluación. Las organizaciones de desarrollo de software tendrán una
herramienta para iniciar y sostener un proceso continuo de mejora. Los directores de
programas tendrán un medio para garantizar que su desarrollo de software está en
consonancia y apoya, las necesidades comerciales de la organización.

5.6.4 CMMI.
Es un modelo de mejora de los procesos de construcción de software que provee los
elementos necesarios para determinar su efectividad. Este modelo puede ser utilizado
como guía para mejorar las actividades de un proyecto, área u organización, ya que
proporciona un marco de referencia para evaluar la efectividad de los procesos
actuales, facilitando con ello la definición de actividades, prioridades y metas para
garantizar la mejora continua. Es el estándar más conocido para la mejora de
procesos en mejora de procesos para el desarrollo de proyectos, gestión de
proveedores y gestión de servicio.

El CMMI establece cinco niveles de madurez los cuales son: Nivel 0: Incompleto El
proceso no se realiza, o no se consiguen los objetivos.

Nivel 1
Inicial o ejecutando: Este es el nivel en donde todas las empresas que no tienen
procesos, es donde el proceso se ejecuta y se logra su objetivo, así sea fuera de
presupuesto y de cronograma.

Nivel 2 Repetible: Se da cuando el éxito de los resultados obtenidos se puede repetir.

Nivel 3
Definido: Significa que la forma de desarrollar proyectos está definida, establecida,
documentada y que existen métricas.
Nivel 4 Administrado: Los proyectos usan objetivos medibles y cuantificables para
alcanzar cubrir las necesidades de los clientes y la organización. Es decir, se usan
métricas para gestionar la organización.

Nivel 5 Optimizado: Los procesos de los proyectos y de la organización están

orientados a la mejora de las actividades, que mediante métricas son identificadas,
evaluadas y puestas en práctica.

5.6.5 MoProSoft.

Es una norma mexicana, basada en procesos para las industrias de software, la cual
sirve para estandarizar operaciones y prácticas en gestión de ingeniería de software,
para así elevar la capacidad de las organizaciones de ofrecer servicios con calidad y
alcanzar niveles internacionales de competitividad. Está enfocado a las Pymes de la
Industria de Software en México. Está dirigido a las empresas o áreas internas
dedicadas al desarrollo y/o mantenimiento de software.

Cuadro comparativo

Estándares y Organismo que regula Aplicable a

Normas

CMMI (SEI) Software Mejora de procesos de construcción de software

Engineering Institute y proyectos de TI.

PSP ISO Permite estimar cuánto se tarda un individuo en

realizar una aplicación de software

PSP-TSP ISO Predice el tiempo y tamaño del software

Administración de calidad

ISO 25000 ISO Establecen un modelo de calidad para el

producto del software, además de definir la
evaluación de la calidad del producto.

IEEE IEEE Serie de documentación para el desarrollo de

software y proyectos de TI

TSP Team Software Es un método de establecimiento y mejora del

Process trabajo en equipo para procesos de software

SPICE Programa de Es una importante iniciativa internacional para

simulación con énfasis apoyar el desarrollo de una Norma Internacional
en circuitos para la Evaluación de procesos del software
integrados
MOPROSOFT ISO Norma mexicana, basada en procesos para las
industrias de software, la cual sirve para
estandarizar operaciones y prácticas en gestión
de ingeniería de software