Introducción

La calidad ha dejado de ser un tópico, y forma parte, es necesario que forme parte de los productos
o servicios que comercializamos para nuestros clientes Esta incorporada en nuestra forma de ver la
vida. Cada vez exigimos mas que los productos o servicios que nos suministran nuestros
proveedores tengan el mayor grado de calidad dentro de un precio razonable. El aforismo de “El
precio se olvida y la calidad perdura" se hace cada vez más patente.

El cliente es el mejor auditor de la Calidad, él exige el nivel que está dispuesto a pagar por ella
pero no mas. Por tanto, debemos de cuantificar cuál es el nivel de Calidad que nos exige para
poder planificar la Calidad de los productos semielaborados que se generen a lo largo del proceso
de producción del producto o servicio final.

Es por ello que los Sistemas de Software son cada vez más importantes en la sociedad actual y
crecen rápidamente en tamaño y complejidad .los software de Calidad, estan basados 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.

La calidad de un software se fundamenta en que cumpla los estándares de calidad exigidos en

todas la etapas de su ciclo de vida, recibiendo asesoramiento en cuanto a la mejora de procesos y
realizando pruebas de software, seleccionando los servicios, técnicas de test y herramientas más
adecuadas, según las necesidades y expectativas marcadas, en materia de: Funcionalidad,
Fiabilidad, Usabilidad, Eficiencia, Mantenimiento y Portabilidad.
.
 Definición de calidad según los modelos y estandares.:

La calidad, por su parte, es una propiedad y cualidad inherente de las cosas, que
permite la comparación entre éstas y otras de su misma especie. Se trata de una
apreciación subjetiva que, respecto a un usuario, implica satisfacer las necesidades y
deseos (si lo logra, es de buena calidad).
Un modelo de calidad es, por lo tanto, un conjunto de prácticas vinculadas a los
procesos de gestión y el desarrollo de proyectos. Este modelo supone una
planificación para alcanzar un impacto estratégico, cumpliendo con los objetivos
fijados en lo referente a la calidad del producto o servicio.
Al implementar un modelo de calidad, una empresa busca desarrollar
sistemáticamente productos y servicios que cumplan con los requerimientos y las
exigencias de los clientes.

Proceso o servicio que le confiere su aptitud para satisfacer unas necesidades

expresadas o implícitas.” En la actualización de la Norma ISO, la 9000:2000, la
definición quedó “Grado en el que un conjunto de características inherentes cumple
con los requisitos”. En esta definición se hace especial énfasis en cumplir los
requerimientos de los consumidores

Calidad de software:

En la industria del software se pueden evidenciar necesidades de satisfacción del

cliente de productos o servicios de software, de reducción de recursos invertidos en
proyectos de software y de la efectiva asignación de recursos humanos. Si hablamos
de la calidad del software, una de las primeras definiciones aseguraba que “la calidad
de un programa o sistema se evaluaba de acuerdo al número de defectos por cada mil
líneas de código.

La definición de la calidad del software según la IEEE, Std. 610-1990, es “el grado
con el que un sistema, componente o proceso cumple los requerimientos especificados
y las necesidades o expectativas del cliente o usuario”

La calidad del software es medible y varía de un sistema a otro o de un programa a

otro. Un software elaborado para el control de naves espaciales debe ser confiable al
nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el
mismo nivel de calidad; mientras que un producto de software para ser explotado
durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible
para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de
explotación.

La calidad del software puede medirse después de elaborado el producto. Pero esto
puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en
el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad
como su control durante todas las etapas del ciclo de vida del software.

Calidad en el software:

La obtención de un software con calidad implica la utilización de metodologías o

procedimientos estándares para el análisis, diseño, programación y prueba del
software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor
confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la
productividad, tanto para la labor de desarrollo como para el control de la calidad del
software.
La política establecida debe estar sustentada sobre tres principios básicos:
tecnológico, administrativo y ergonómico.

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

software.
El principio administrativo contempla las funciones de planificación y control del
desarrollo del software, así como la organización del ambiente o centro de ingeniería
de software.
El principio ergonómico define la interfaz entre el usuario y el ambiente
automatizado.
La adopción de una buena política contribuye en gran medida a lograr la calidad del
software, pero no la asegura. Para el aseguramiento de la calidad es necesario su
control o evaluación.

Aseguramiento de la calidad del software( SQA):

es un conjunto de actividades sistemáticas y planeadas para asegurar que los procesos
y productos de software cumplen con los requerimientos, estándares procedimientos.

El Aseguramiento de la Calidad del Software es el conjunto de actividades

planificadas y sistemáticas necesarias para aportar la confianza que el software
satisfará los requisitos dados de calidad. Este aseguramiento se diseña para cada
aplicación antes de comenzar a desarrollarla y no después. El Aseguramiento de la
Calidad del Software engloba:

Un enfoque de gestión de calidad.

Métodos y herramientas de Ingeniería del Software.
Revisiones técnicas formales en el proceso del software.
Una estrategia de prueba multiescala.
El control de la documentación del software y de los cambios realizados.
Procedimientos para ajustarse a los estándares de desarrollo del software.
Mecanismos de medición y de generación de informes.
Rol de SQA
El rol para SQA es brindar a Metodología de Desarrollo de Software la administración
la seguranza de que procesos oficialmente establecidos están siendo implementados.
Y asegura que:
Una apropiada este establecida
Que los proyectos utilicen estándares y procedimientos en su trabajo
Que la documentación sea creada para mantenimiento y mejoramiento
La administración de configuración de software este adecuada para controlar cambios
Se realicen pruebas y que se aprueben
Cualquier deficiencia y desviaciones sean identificadas y llevadas con atención a la
administración.

Necesidad de la calidad y de sus procesos de aseguramiento:

Fortalecer el plan de operación (plan de calidad)

Capacitación en las especificaciones directamente por el supervisor
Preparación de todos los materiales, componentes, herramientas, instrucciones para la
operación por parte del personal de producción.
Establecimiento de las condiciones de arranque de las operaciones necesarias por
parte del supervisor.
Operación física por parte de los operadores, mientras se da seguimiento a los
procedimientos. Plan de calidad
Revisiones que realizan los operadores sobre su propio trabajo (control estadístico de
proceso o pre control).
Inspección y registro que realizan los operarios sobre sus propias condiciones de
operación.
Revisiones diarias de la maquinaria, el equipo, las herramientas y los registros que se
utilizan diariamente, tanto antes como después de su uso, por parte de los supervisores
y operadores para asegurar:
Calidad, cantidad, tiempo y costo del producto especificados
Reducción de error en el proceso
Aumento de la productividad
Disminución del índice de rotación
Aumento de la disponibilidad
Reducción del tiempo muerto
Aumento de la satisfacción de las áreas que realizan las siguientes etapas.

Beneficios de los procesos de la calidad en el software:

Los beneficios que se pueden obtener como resultado de aplicar los procesos de aseguramiento de
calidad son muchos y variados, algunos que se pueden citar con brevedad son:

1. Se detectan problemas rápidamente, Es posible identificar problemas en tempranas etapas del

desarrollo de productos de software, ayudando al desarrollador a corregirlos inmediatamente y
poder avanzar con más rapidez.

2. Se crean y se siguen estándares de trabajo, Con apoyo del proceso de aseguramiento de calidad,
se pueden establecer estándares tan diversos como son los de codificación o de documentación,
los cuales apoyan a uniformizar y consolidar el proceso de desarrollo.

3. Se verifica que los objetivos individuales vayan acordes con los objetivos de la organización, Se
busca y se recomienda que los requerimientos expuestos por usuarios finales estén alineados con
los objetivos globales de la empresa, facilitando así el logro de los mismos y la integración total de
los usuarios a la organización.

4. Se recomiendan métodos para realizar el trabajo, Las prácticas de aseguramiento de calidad,

como son muy robustas ya que aplican técnicas muy completas de medición, pueden proponer en
un momento dado qué métodos se ajustan más a la naturaleza del producto a ser desarrollado,
teniendo como efecto final que el producto tenga más posibilidades de ser un producto con
calidad.

5. Se evita incurrir en costos innecesarios, Como un efecto generalizado de algunos de los puntos
mencionados con anterioridad, la práctica de procesos de aseguramiento de calidad lleva a las
organizaciones a evitar costos no deseados como pueden ser todos aquellos ocasionados por
mantenimiento correctivo.

6. Se planea la calidad, Está claro que el concepto de calidad no es algo que se da de una manera
automática e impredeciblemente. Es algo que se busca. Por lo mismo, se debe de planear, construir
e implantar en el producto .
 Problemas y costos de la calidad en el software:
Uno de los principales problemas con los que se encuentra la actividad de aseguramiento de la
calidad en el software es la falta de apoyo por parte de la alta dirección de las organizaciones. Este
apoyo es esencial para que la función de aseguramiento de calidad tenga éxito. Los costos
económicos de la función de aseguramiento de la calidad en el software se han estimado que varía
entre un 2.5 y 5 por ciento del costo total de un proyecto de desarrollo de un producto de software.

El costo se localiza en las actividades (como son revisiones periódicas y constantes de las
aplicaciones) que tienen que realizar algunos desarrolladores de software, mismas que se deben de
integrar a sus actividades ordinarias .

Control de la Calidad

Son las Técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos
relativos a la calidad, centradas en dos objetivos fundamentales:

1. Mantener bajo control los Productos de Desarrollo de software,

2. Eliminar las causas de los defectos en las diferentes fases del ciclo de vida, que puedan
presentarse en los desarrollos de los productos de software.

Aseguramiento de Calidad vs. Control de la Calidad.

Es de suma importancia entender las diferencias que existen entre el control de la calidad y el
aseguramiento de la calidad. El aseguramiento de la calidad aprovecha los resultados del control
de calidad para evaluar y mejorar los procesos con los que se desarrolla el producto. Esto dicho, el
control de calidad se enfoca en productos, mientras que el aseguramiento de la calidad lo hace en
los procesos .
Gestión de la calidad

Se debe conocer:
Control de calidad: "Conjunto de técnicas y actividades de carácter operativo, utilizadas para
verificar los requerimientos relativos a la calidad del producto o servicio".
Control de la calidad del software: Técnicas y actividades de carácter operativo, utilizadas para
verificar los requisitos relativos a la calidad, centradas en mantener bajo control el proceso de
desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
El control de la calidad del software está centrado en dos objetivos fundamentales:
Mantener bajo control un proceso.
Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
En general, se puede decir que el control de de la calidad del software son las actividades para
evaluar la calidad de los productos desarrollados.

Sistema de calidad:
Básicamente, tiene que ver con la aplicación de técnicas y medidas para el mejoramiento de los
procesos internos de una compañía, sin importar cuál sea el área en la que se desempeñe.

Pero también surge la incógnita de para qué sirven estos sistemas o con qué objetivo se
implementan dentro de una organización. La respuesta es muy sencilla: el control de calidad se
centra en planear, controlar y vigilar los elementos que hacen posible la prestación de un buen
servicio para que, de esa forma, se consiga satisfacer a los clientes.

El control de calidad también puede definirse como las normas y estándares internacionales que se
ejecutan para mejorar los procedimientos de una empresa.

Certificación de la calidad:

las certificaciones de calidad están relacionadas con el establecimiento previo de una norma o
referencial entre todas las partes que tienen interés sobre un producto como pueden ser
proveedores, compradores y usuarios, o gobiernos, entre otros. De esta manera, una vez
alcanzado un consenso sobre las características básicas y mínimas que tiene que tener un producto
o servicio, se llega a la certificación.

Así, la certificación de calidad será el resultado de un proceso en el que una serie de auditores
calificados de una entidad de certificación acreditada para ello garantice que un producto o un
sistema de gestión se ajustan a las características de la norma que se ha tomado como referencia.

Factores que determinan la calidad de software:

Se clasifican en tres grupos:

• Operaciones del producto: características operativas.
– Corrección (¿Hace lo que se le pide?): El grado en que una aplicación satisface sus
especificaciones y consigue los objetivos encomendados por el cliente.
– Fiabilidad (¿Lo hace de forma fiable todo el tiempo?):El grado que se puede esperar de una
aplicación lleve a cabo las operaciones especificadas y con la precisión requerida.
– Eficiencia (¿Qué recursos hardware y software necesito?): a cantidad de recursos hardware y
software que necesita una aplicación para realizar las operaciones con los tiempos de respuesta
adecuados.
– Integridad (¿Puedo controlar su uso?): El grado con que puede controlarse el acceso al software
o a los datos a personal no autorizado.
– Facilidad de uso (¿Es fácil y cómodo de manejar?): El esfuerzo requerido para aprender el
manejo de una aplicación, trabajar con ella, introducir datos y conseguir resultados.
• Revisión del producto: capacidad para soportar cambios.
– Facilidad de mantenimiento (¿Puedo localizar los fallos?): El esfuerzo requerido para localizar y
reparar errores.
– Flexibilidad (¿Puedo añadir nuevas opciones?): El esfuerzo requerido para modificar una
aplicación en funcionamiento.
– Facilidad de prueba (¿Puedo probar todas las opciones?): El esfuerzo requerido para probar una
aplicación de forma que cumpla con lo especificado en los requisitos.
• Transición del producto: adaptabilidad a nuevos entornos.
– Portabilidad (¿Podré usarlo en otra máquina?): El esfuerzo requerido para transferir la aplicación
a otro hardware o sistema operativo.
– Reusabilidad (¿Podré utilizar alguna parte del software en otra aplicación?): Grado en que partes
de una aplicación pueden utilizarse en otras aplicaciones.
– Interoperabilidad (¿Podrá comunicarse con otras aplicaciones o sistema informáticos?: El
esfuerzo necesario para comunicar la aplicación con otras aplicaciones o sistemas informáticos.

Clasificación de los factores:

Factores que determinan la calidad del software:

Se pueden clasificar en dos grandes grupos (Pressman):

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.

Modelos de calidad:

Los modelos de calidad son referencias que las organizaciones utilizan para mejorar su gestión.
Los modelos, a diferencia de las normas, no contienen requisitos que deben cumplir los sistemas
de gestión de la calidad sino directrices para la mejora. Existen modelos de calidad orientados a la
calidad total y la excelencia, modelos orientados a la mejora, modelos propios de determinados
sectores e incluso modelos de calidad que desarrollan las propias organizaciones.

Principales características de los modelos de Calidad total :

cada uno de estos modelos posee una serie de características propias que los hace diferentes. Cada
método se basa en unos principios concretos o le concede mayor importancia a unos elementos
sobre otros, sin embargo, todos ellos comparten una serie de características comunes y unos
principios por los que se debe regir la calidad.

√De carácter voluntario. Los modelos de Excelencia no son de cumplimiento obligatorio. Cada
empresa, de manera voluntaria, decide asumir ese modelo de gestión basado en la Excelencia y se
compromete a llevarlo a respetarlo.
√Constituyen un marco de referencia para mejorar los procesos y alcanzar la calidad total. Los
diversos modelos señalan los requisitos necesarios y establecen una serie de recomendaciones que
orientan la puesta en práctica del método, pero no son prescriptivos, no se debe acatar como si
fuera una ley. Las empresas deberán adaptarlo según sus necesidades.

√Se pueden adaptar para cualquier tipo de empresa. Los métodos de Excelencia están diseñados
para que puedan llevarse a cabo en cualquier tipo de empresa, con independencia de su tamaño o
sector. Las empresas sólo tendrán que adaptar el modelo seleccionado conforme a sus
particularidades.

√Sirven como método de autoevaluación. Los modelos de Excelencia, además de constituir las
bases para optar a los premios que dan nombre y servir de referente para implantar un sistema de
gestión empresarial basado en la Excelencia, también permiten llevar a cabo una autoevaluación
para analizar si se cumplen con las exigencias necesarias y averiguar qué procesos se deben
mejorar para cumplir los objetivos de Calidad Total propuestos.

√No prevén auditorías externas propiamente dichas. Estos modelos no plantean auditorías externas
que lleven un riguroso control del cumplimiento de las condiciones necesarias, sin embargo, sí que
se plantean evaluaciones con este fin.

√No son certificables. La implementación de estos modelos de Excelencia no conlleva la

consecución de un certificado, tal y como ocurre con la norma ISO 9001 de calidad, aunque sí se
puede obtener un sello con diferentes puntuaciones, como el concedido por el modelo EFQM.

Para el producto Gilb:

El modelo de Gilb aparece alrededor de los años 1986 - 1988. Este modelo utiliza el termino de
‘atributos’ los cuales hacen referencia a la medida de calidad que determinado sistema (producto)
a evaluar posee. El modelo muestra especial interés en aquellos atributos de calidad que son de
interés para el usuario con miras a satisfacer los requerimientos o necesidades de éste. Los
atributos que GILB definió para establecer la calidad de un sistema son los siguientes:

Capacidad de trabajo: Este atributo busca medir la capacidad del sistema para ejecutar tareas.
Tiene como sub atributos la capacidad de almacenamiento, capacidad de proceso y capacidad de
respuesta.
Disponibilidad: Este atributo mide la capacidad del sistema para realizar un trabajo de forma útil.
Adaptabilidad: Hace referencia a la medida de la capacidad que tiene el sistema para sufrir
modificaciones.
Utilizabilidad: Mide la facilidad con la cual las personas serán capaces y estarán motivadas para
hacer uso del sistema.
El modelo proporciona ciertas características que proveen indicadores útiles para describir la
calidad de la aplicación del sistema y usa métricas detalladas para dicho fin.

GQM:

Goal Question Metric busca formas por medio de las cuales se puedan definir las métricas para
medir los avances que ocurren aplicando preguntas que tengan que ver con el tema del proyecto.

En este modelo se presentan tres niveles:

Nivel Conceptual:
aquí se define un objetivo para un objeto, se tienen en cuenta varios puntos de vista con relación
a un entorno particular.

Nivel Operacional: se utilizan varias preguntas que permitan definir

los modelos del objeto de estudio, con el fin de establecer cuál es el logro de un objetivo
específico.

Nivel Cuantitativo: Un grupo de métricas se asocian con cada una de las preguntas para
responderlas utilizando medidas.
En el modelo GQM encontramos objetivos comerciales que se utilizan en la identificación de las
mediciones correctas. También se realizan otros pasos para almacenar los datos de medición;
luego esta información servirá para tomar decisiones y realizar mejoras.

MCCall:

El modelo de McCall fue el primero en ser presentado en el 1977 y se origino motivado por Air
Forcé y Dod. Este modelo se focaliza en el producto final identificando atributo claves desde el
punto de vista del Cliente. Esto atributos se denominan factores de calidad y son normalmente
atributos externos pero también se incluyen algunos atributos internos.

Cada atributo externo atributo se dominan factores de calidad los cuales son abstractos para ser
medidos directamente por lo cual se introduce un atributo de bajo nivel denominado criterios de
calidad.

Según McCall algunos criterios de calidad son atributos internos que tienen efectos directos en
atributos externos.
El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el
usuario puede contemplar la calidad de un producto, basándose en once factores de calidad
organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios:

Eje:operación del producto.

Factor: facilidad de uso, integridad , corrección.

Criterios:
√Facilidad de operación: Atributos del software que determinan la facilidad de operación del
software.
- Facilidad de comunicación: Atributos del software que proporcionan entradas y salidas
fácilmente asimilables.
- Facilidad de aprendizaje: Atributos del software que facilitan la familiarización inicial del
usuario con el software y la transición del modo actual de operación.
- Formación: El grado en que el software ayuda para permitir que nuevos usuarios apliquen el
sistema.

√Control de accesos. Atributos del software que proporcionan control de acceso al software y los
datos que maneja.
- Facilidad de auditoría: Atributos del software que facilitan la auditoría de los accesos al software.
- Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o los datos.

√Completitud: Atributos del software que proporcionan la implementación completa de todas las
funciones requeridas.
- Consistencia: Atributos del software que proporcionan uniformidad en las técnicas y notaciones
de diseño e implementación.
- Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los
requisitos a la implementación con respecto a un entorno operativo concreto.

Eje : operación del producto.

Factor:fiabilidad , eficiencia.
Criterios:

-√Precisión: Atributos del software que proporcionan el grado de precisión requerido en los
cálculos y los resultados.
-Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo
condiciones no usuales.
-Modularidad: Atributos del software que proporcionan una estructura de módulos altamente
independientes.
-Simplicidad: Atributos del software que posibilitan la implementación de funciones de la forma
más comprensible posible.
- Exactitud: La precisión de los cálculos y del control.

√Eficiencia en ejecución: Atributos del software que minimizan el tiempo de procesamiento.

-Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de
almacenamiento necesario.

Eje : revisión del producto .

Factor: facilidad de mantenimiento, facilidad de prueba, flexibilidad, reusabilidad,
interoperabilidad y portabilidad.

Criterios:
√Concisión: Atributos del software que posibilitan la implementación de una función con la menor
cantidad de códigos posible.
-Auto descripción: Atributos del software que proporcionan explicaciones sobre la
implementación de las funciones.

√Instrumentación: Atributos del software que posibilitan la observación del comportamiento del
software durante su ejecución para facilitar las mediciones del uso o la identificación de errores.

√Capacidad de expansión: Atributos del software que posibilitan la expansión del software en
cuanto a capacidades funcionales y datos.
-Generalidad: Atributos del software que proporcionan amplitud a las funciones implementadas.

√Independencia entre sistema y software: Atributos del software que determinan su dependencia
del entorno operativo.
- Independencia del hardware: Atributos del software que determinan su dependencia del
hardware.

√Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos

de comunicación e interfaces estándar.
-Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos
estándar.
-Estandarización en los datos: El uso de estructuras de datos y de tipos estándar a lo largo de todo
el programa.f

√Independencia entre sistema y software.

- Independencia del hardware.
FURPS:
Modelo de calidad propuesto por Robert Grady y Hewlett Packard Co (HP) en 1987. Sustenta por
un lado 5 características de las cuales se deriva su nombre (Funcionalidad, Facilidad de Uso,
Confiabilidad, Performance y Facilidad de Soporte), y por otro, que los requisitos se clasifiquen
en dos categorías: requisitos funcionales (F), que son los que especifican funciones que el sistema
debe ser capaz de realizar sin tener en cuenta las restricciones físicas; y requerimientos no
funcionales (URPS), que puntualizan atributos del sistema o del medio ambiente del sistema.

Este modelo dispone de una serie de test para las diferentes etapas del producto, los usuarios
prueban el producto antes de comercializarlo y obtener un “leed-back”. Asimismo, existe un plan
de soporte definido que incluye una base de datos con todos los errores registrados para poder
subsanar los errores.

El modelo FURPS incluye, además de los factores de calidad y los atributos, restricciones de
diseño y requerimientos de implementación, físicos y de interfaz. Una limitación de este modelo
de calidad es que no tiene en cuenta la portabilidad de los productos software que se estén
considerando, factor digno de consideración en función de las exigencias actuales que recaen
sobre el proceso de desarrollo del software. La funcionalidad puede incluir: Características de
sistemas. Capacidades. Seguridad.
Los requerimientos de usabilidad pueden incluir subcategorías tales como: Factores humanos.
Estética. Consistencia. Documentación.
La confiabilidad incluye: Recuperabilidad. Precisión. Predicción.
Prestación: Velocidad. Eficiencia. Consumo. Productividad. Tiempo de respuesta.
Soporte: Adaptabilidad. Extensibilidad.
Mantenibilidad. Compatibilidad. Configurabilidad.

CMML:

El modelo CMMI DEV, cuyo objetivo esbservir de guía para mejorar el proceso de desarrollo de
software, puede aplicarsede dos formas distintas: una utilizándolo para mejorar algunas
actividades, cuyo conjunto corresponde a una de las llamadas áreas de proceso, hasta alcanzar un
nivel esperado y otra mejorando un grupo establecido de actividades, organizadas en áreas de
proceso. Los distintos caminos se denominan representaciones. El primero es la “representación
continua” y el segundo, la “representación por etapas”.
En la representación por etapas, la preferida hasta ahora por las organizaciones, el primer nivel
que se evalúa es el 2 y se llega hasta el 5. En el nivel 2 hay siete áreas de proceso:

Gestión de Requerimientos (REQM, Ingeniería).

• Planificación de Proyecto (PP, Gestión de proyectos).
• Monitorización y Control de Proyecto (PMC, Gestión de proyectos).
• Gestión de Acuerdos con Proveedores (SAM, Gestión de proyectos).
• Medición y Análisis (MA, Soporte).
• Aseguramiento de la Calidad de Proceso y de Producto (PPQA, Soporte).
• Gestión de Configuración (CM, Soporte).

En el nivel 3 a esas siete áreas se le agregan otras once:

• Gestión Integrada de Proyecto + IPPD (IPM + IPPD Gestión de proyectos).
• Definición de Procesos de la Organización + IPPD (OPD + IPPD Gestión de Proyectos).
• Enfoque en los Procesos Organizativos (OPF Gestión de proyectos)
°Gestión de Riesgos (RSKM, Gestión deproyectos).
• Formación Organizativa (OT, Gestión de proyectos).
• Integración de Producto (PI, Ingeniería).
• Desarrollo de Requerimientos (RD, Ingeniería).
• Solución Técnica (TS, Ingeniería).
• Validación (VAL, Ingeniería).
• Verificación (VER, Ingeniería).
• Análisis de Decisiones y Resolución (DAR, Soporte).
PSP:
El PSP (Personal Software Process o Proceso Personal de Software) es un conjunto de prácticas
para la gestión del tiempo y mejora de la productividad personal de los programadores o
ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y
diseñado para emplearse en organizaciones que ya usen modelos de procesos como el CMMI
(Capability Maturity Model Integration) o ISO 15504. El PSP fue propuesto por Watts Humphrey
en el año 1995 y originalmente estaba dirigido solamente a estudiantes.

El origen del PSP se dio debido a ciertos problemas que se empezaron a presentar en forma
recurrente respecto al proceso de desarrollo de software. Por ejemplo:

Imposibilidad de cumplir con las fechas de entrega

Defectos detectados en el último minuto
Incapacidad de demostrar el avance del desarrollo, no hay una medición clara ni exacta
Esfuerzos duplicados y por ende desperdicio de recursos
Clientes insatisfechos con el servicio brindado

El pensamiento de Humphrey es que la calidad del software está dada por la calidad de los
procesos usados para desarrollar y mantener el software. Dentro de las principales ventajas están:

Ayuda a estimar, planear y desarrollar sistemas de software

Orientado a manejar de forma continua las habilidades
Exige disciplina
Brinda documentación clara sobre:

Registros
Procedimientos
Formularios y plantillas
Estándares.

TSP:
El team process software inicio como una herramienta capaz de ayudarle a los equipos de gerentes
de proyectos, así como a los ingenieros a organizar y producir proyectos de software a gran escala;
se dio a conocer en 1996 y fue desarrollado por el ingeniero y físico Watts S. Humprey, el cual
publico el primer reporte técnico en el 2000. Humprey buscaba dotar a sus estudiantes de
ingeniería de software, una visión total del ciclo de vida del software.

Esta novedosa herramienta es considerada como una metodología para administrar el trabajo de
mejora y desarrollo de los procesos de software, además de garantizar un entorno de trabajo
agradable y natural para los equipos. El TSP brinda un conjunto de pasos bien estructurados que
indican qué hacer en cada fase del desarrollo del proyecto y muestra cómo conectar cada fase para
construir un producto completo, además brinda una ayuda acerca de como conformar equipos para
el desarrollo de software de calidad (Humphrey, 2000a; 2000b).
Objetivos de Team Process Software:
Maximizar la calidad del software en detrimento de los costos
Formar equipos que sean capaces de planear y registrar su trabajo, establecer metas bien definidas
y sean aptos para realimentar su propio trabajo mediante la medición del mismo.
Brindar un punto de vista a los gerentes y lideres de proyecto acerca de como monitorear y como
motivar a sus equipos de trabajo para sacar el máximo potencial del mismo.
Establecer una guía para el mejoramiento en organizaciones maduras; asi como acelerar la mejora
continua de procesos.

BOEHM:
Este se basa en que el software debe hacer lo que el usuario quiere que haga, por lo tanto se espera
que el software:

√ Utilice los recursos del computador correcta y eficientemente.

√Sea fácil de usar y de aprender para los usuarios.

√Estar bien diseñado, codificado y ser probado y mantenido fácilmente.

La estructura presenta 3 niveles para las características: de alto nivel, de nivel intermedio y
características primitivas. Cada una de estas características contribuye al nivel general de calidad.

Características de alto nivel

Estas características representan requerimientos generales de uso:

√Utilidad, cuan (usable, confiable, eficiente) es el producto en sí mismo.

√Mantenimiento, cuan fácil es modificarlo, entenderlo y retestearlo.

√ Utilidad general, si puede seguir usándose si se cambia el ambiente.

Características de nivel intermedio

Estas características representan los factores de calidad de Boehm:

√Portabilidad(Utilidad general)

√Fiabilidad ( Utilidad per-se)

√ Eficiencia ( Utilidad per-se)

√Usabilidad ( Utilidad per-se)

√Capacidad de prueba ( Mantenibilidad)

√ Flexibilidad (Mantenibilidad)

Características Primitivas

Este es el nivel más bajo y corresponde a características directamente asociadas a una o dos
métricas de calidad:

√Portabilidad

√ Independencia de dispositivos

√ Auto-contención de confiabilidad.

√Auto-contención

√Exactitud

√ Completitud

√ Consistencia

√ Robustez/Integridad

Para el proceso:
CMDI dev:
es un modelo de referencia que cubre las

actividades para desarrollar tanto productos como servicios, contiene

prácticas que cubren la gestión de proyectos, la gestión de procesos, la

ingeniería de sistemas, la ingeniería de hardware, la ingeniería de software y

otros procesos de soporte utilizados en el desarrollo y mantenimiento.

PSP:
Proceso
La entrada de PSP son los requerimientos; el documento de requerimientos es completado y
entregado al ingeniero.

PSP0, PSP0.1 (Introduce la disciplina y la medición al proceso)

PSP0 tiene 3 fases: planeación, desarrollo (diseño, codificación, pruebas) y un post mortem. Se
establece una base del proceso normal de medición: tiempo tomado programando, fallos
inyectados/removidos, tamaño de un programa. En un post mortem el ingeniero asegura que todos
los datos del proyecto hayan sido registrados y analizados correctamente. PSP0.1 agrega un
estándar de código, una medida de tamaño y el desarrollo de un plan de mejora personal PIP. En el
PIP el ingeniero registra ideas para mejorar su propio proceso.

PSP1, PSP1.1 (Introduce estimación y planeación)

Teniendo como base los datos recolectados en PSP0 y PSP0.1, el ingeniero estima el tamaño que
tendrá el nuevo programa y prepara un reporte de pruebas (PSP1). Los datos recolectados para
proyectos previos se usan para estimar el tiempo total. Cada proyecto nuevo registrará el tiempo
gastado actualmente. Esta información es usada para tareas de agendamiento, planeación y
estimación(PSP1.1).

PSP2, PSP2.1 (Introduce manejo de calidad y diseño)

PSP2 agrega dos fases nuevas: revisión de diseño y de código. Se enfoca en la prevención de
defectos y su remoción. Los ingenieros aprenden a evaluar y mejorar su proceso midiendo la
extensión de sus tareas y la cantidad de defectos inyectados y removidos en cada fase de
desarrollo. Los ingenieros construyen y usan listas de chequeo para diseño y revisión de código.

PSP2.1 introduce especificaciones de diseño y técnicas de análisis.

(PSP3 es un legado de PSP que ha sido sustituido por TSP.)

TSP:
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.

Estándares de calidad:
Qué es un estándar?
De acuerdo con la definición de la Real Academia Española, “estándar es aquello que sirve como
tipo, modelo, norma, patrón o referencia”.

Qué es un estándar de calidad?

Estándar de calidad es el que reúne los requisitos mínimos en busca de la
excelencia dentro de una organización institucional.
ISO/IEC JTC1-SC7
Ingeniería de Software y de Sistemas.
IEEE ? CS
ISO 9126 ? Calidad del producto.
ISO 14598 ? Evaluación de productos de software.
ISO 12119 ? Requerimientos de Calidad y Testing de COTS.
ISO 15939 ? Proceso de medición de software.
Para el producto:
ISO/IEC 9126:
ISO 9126 era un estándar internacional para la evaluación de la calidad del software. Fue
reemplazado en 2005 por el conjunto de normas SQuaRE, ISO 25000:2014, la cual desarrolla los
mismos conceptos.
El estándar provee un entorno para que las organizaciones definan un modelo de calidad para el
producto software. Haciendo esto así, sin embargo, se lleva a cada organización la tarea de
especificar precisamente su propio modelo. Esto podría ser hecho, por ejemplo, especificando los
objetivos para las métricas de calidad las cuales evalúan el grado de presencia de los atributos de
calidad.

Un producto software está definido en un sentido amplio como: los ejecutables, código fuente,
descripciones de arquitectura, y así. Como resultado, la noción de usuario se amplía tanto a
operadores como a programadores, los cuales son usuarios de componentes como son bibliotecas
software.

El modelo incluye métricas internas y externas. Métricas internas son aquellas que no dependen de
la ejecución del software (medidas estáticas), mientras que las métricas externas son aquellas
aplicables al software en ejecución. La calidad en las métricas de uso están sólo disponibles
cuando el producto final es usado en condiciones reales. Idealmente, la calidad interna no
necesariamente implica calidad externa y esta a su vez la calidad en el uso.

ISO 14598:
La norma ISO/IEC 14598 establece un marco de trabajo para evaluar la calidad de los productos
de software en 6 etapas. Proporciona métricas y requisitos para los procesos de evaluación.

Beneficios del estándar:

Los desarrolladores pueden usar los resultados de la evaluación con el fin de hacer mejoras en el
producto o tomar decisiones sobre la estrategia de evolución que seguirá el producto software.
Para los proveedores de un producto, un beneficio de dicha evaluación puede ser añadir un valor
al producto, puesto que el hecho de que cumple el estándar es sinónimo de que el producto posee
cierta calidad.
Para los adquirientes del producto, los resultados de evaluación pueden ser usados como un dato
objetivo a la hora de decidir si adquirir o no el producto.
Para la industria en general, la difusión de la evaluación de productos de software ayudará a que se
utilice la calidad como un argumento de marketing.

ISO 2500 (SQUARE):

El objetivo general de la creación del estándar ISO/IEC 25000 SQuaRE (System and Software
Quality Requirements and Evaluation) es organizar, enriquecer y unificar las series que cubren dos
procesos principales: especificación de requisitos de calidad del software y evaluación de la
calidad del software, soportada por el proceso de medición de calidad del software.

ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements and
Evaluation), es una familia de normas que tiene por objetivo la creación de un marco de trabajo
común para evaluar la calidad del producto software.

Ventajas :

√Para la organización:
Alinea los objetivos del software con las necesidades reales que se le demandan.
Evitando ineficiencias y maximizando la rentabilidad y calidad del producto de software. Por otro
lado, certificar el software aumenta la satisfacción del cliente y mejora la imagen de la empresa.
Cumplir los requisitos contractuales y demostrar a los clientes que la calidad del software es
primordial.
El proceso de evaluaciones periódicas ayuda a supervisar continuamente el rendimiento y la
mejora.

√Para los clientes:

Al demostrar el compromiso de la organización con la calidad del software.

Para el proceso:
ISO/IEC 12207:
ISO/IEC 12207 Information Technology / Software Life Cycle Processes, es el estándar para los
procesos de ciclo de vida del software de la organización ISO.

Procesos
Los procesos se clasifican en tres tipos: procesos principales, procesos de soporte y procesos de la
organización. Los procesos de soporte y de organización deben existir independientemente de la
organización y del proyecto ejecutado. Los procesos principales se instancian de acuerdo con la
situación particular.

Procesos principales.
Adquisición.
Suministro.
Desarrollo.
Operación.
Mantenimiento.
Destrucción
Procesos de soporte.
Gestión de la configuración.
Aseguramiento de calidad.
Verificación.
Validación.
Revisión conjunta.
Auditoría.
Resolución de problemas.
Procesos de la organización.
Gestión.
Infraestructura.
Mejora.
Recursos Humanos.

ISO/IEC 15504:
La norma ISO/IEC 15504 ha sido denominada como Determinación de la Capacidad de Mejora
del Proceso de Software o SPICE nos propone un modelo para la evaluación de la capacidad en
los procesos de desarrollo de productos software.
a norma ISO/IEC 15504 se trata de una herramienta con los siguientes objetivos:Es necesario
proponer y desarrollar un estándar de evaluación de procesos de softwareEvaluar el desempeño
mediante la experimentación en la industria emergente del desarrollo de softwarePromover la
transferencia de tecnología de la evaluación de procesos de software a la industria del software a
nivel mundial

Conclusión:
Aunque se es consciente de que el abordar una auditoría sólo con este bagaje no es suficiente. Un
buen auditor en Tecnologías de la Información necesita tener una amplia experiencia en las
distintas funciones de dicha actividad, estar muy al día en las distintas metodologías, procesos y
herramientas que se emplean, de forma que le sea fácil detectar los defectos en los planes, en los
productos y en los procesos, así como estar capacitado para poder proponer recomendaciones.
Se reconoce que no es una tarea fácil, pero precisamente por ello es altamente gratificante el
alcanzar un éxito que satisfaga los intereses, en muchas ocasiones contrapuestos, de las partes
involucradas, consiguiendo de la entidad auditada el reconocimiento de la profesionalidad del
auditor al conseguir detectar los problemas existentes y proponer soluciones, y de la parte que
promovió la auditoría el conseguir que se pueda conocer en dónde residían los problemas que no
permitían alcanzar los objetivos deseables.

Pero debemos recordar que esta actividad no es un arte, sino una técnica, y como tal debe seguirse
un orden y un método en el que nada se da por supuesto si no existe una evidencia objetiva que lo
acredita.

El desarrollo de software es una actividad que requiere de roles y de responsabilidades, esas

responsabilidades deben estar bien delimitadas.
Los roles y responsabilidades varían de empresa a empresa y están dados por las metodologías y
características de los equipos de trabajos.

En términos generales se puede concluir que la calidad del software puede parecer un concepto
alejado de la vida diaria de la mayoría de las personas, pero nada más lejos de la realidad. Cuando
en nuestro ordenador aparece un mensaje de error o una pantalla azul, estamos ante un problema
de calidad del software; cuando un fallo en el sistema de gestión aeroportuaria provoca retrasos,
pérdidas de maletas o inutiliza pantallas de información, estamos ante un problema de calidad del
software;Los fallos de software afectan a todos los sectores y a todos los países, pero si bien es
cierto que Los auténticos profesionales y las empresas bien organizadas son prudentes y saben que
deben aplicar distintas técnicas de control y prevención, además de un buen proceso de desarrollo.