TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO ZACATECAS

UNIDAD V. Calidad de Software.

Presenta
Esaú Antonio Ventura Ruiz Martinez
Empresa
“”

M.C. CINTHYA YERANIA CASAS RAMIREZ

Zacatecas, Zac. a 21 de noviembre del 2024

1
Índice.

Índice.
5.1 Definición de calidad.
5.2 Importancia de la calidad.
5.3 Factores de calidad.
5.4 Aseguramiento de la calidad.
5.5 Estándares y métricas de calidad.
Estándares
Métricas
5.6 Modelos de madurez.
5.6.1 Enfoque de procesos.
5.6.2 PSP y TSP.
5.6.3 SPICE.
5.6.4 CMMI.
5.6.5 MoProSoft.
Referencias.

2
 5.1 Definición de calidad.

La calidad, en términos generales, se entiende como el nivel en que un producto o

servicio satisface los requisitos y expectativas establecidos por el cliente o usuario
final. Esto implica cumplir con especificaciones y responder de manera constante y
confiable a las necesidades.

En el ámbito del software, la calidad se describe como la capacidad de una solución

desarrollada para ajustarse a los requerimientos y necesidades específicas de los
usuarios o clientes, logrando este objetivo a través de procesos bien definidos. En
esencia, se refiere al conjunto de características propias de un producto que le
permiten satisfacer necesidades tanto explícitas como implícitas.

En ingeniería de software, la calidad puede abordarse desde dos perspectivas

principales:

● Cumplimiento de requisitos: El software debe alinearse con las

especificaciones planteadas al inicio del proyecto.
● Satisfacción del usuario: Más allá de los aspectos técnicos, el software
debe ser confiable, fácil de usar y ajustarse a las expectativas implícitas del
cliente.

5.2 Importancia de la calidad.

Según la Norma UNE 66-001-92, basada en la ISO 8402, la calidad se define como
el conjunto de características de un producto o servicio que le otorgan la capacidad
de satisfacer necesidades explícitas o implícitas. En el caso del software, garantizar
su calidad requiere el uso de metodologías y procedimientos estandarizados en las
etapas de análisis, diseño, programación y pruebas. Estos métodos buscan unificar
la filosofía de trabajo para mejorar la confiabilidad, la mantenibilidad y la facilidad de
prueba, al tiempo que aumentan la productividad tanto en el desarrollo como en el
control de calidad del software.

La calidad del software puede interpretarse de las siguientes maneras:

● La totalidad de funciones y características del software determinan su

capacidad para satisfacer necesidades específicas, como el cumplimiento de
especificaciones.
● El nivel en que el software posee una combinación de atributos deseados.
● La percepción del cliente o usuario respecto a la capacidad del software para
cumplir con sus expectativas generales.

3
 ● Las características globales del software determinan en qué medida satisface
las expectativas de quienes lo utilizan.

5.3 Factores de calidad.

Los factores de calidad del software son un conjunto de atributos que determinan
qué tan bien satisface los requisitos y expectativas establecidos. Estos se dividen en
las siguientes categorías principales:

● Factores de producto

Se centran en las características internas del software que influyen en su

capacidad para cumplir las funciones previstas:

- Corrección: Garantiza que el software cumpla con los requisitos

funcionales y no funcionales especificados.
- Fiabilidad: Evalúa la capacidad del software para operar sin fallos
durante un tiempo definido y bajo condiciones específicas.
- Eficiencia: Implica el uso óptimo de recursos como memoria,
procesador, almacenamiento y energía.
- Usabilidad: Mide qué tan fácil es para los usuarios aprender y utilizar
el sistema de manera intuitiva.

● Factores de mantenimiento

Relacionados con la facilidad para realizar cambios, correcciones o mejoras

en el software a lo largo de su ciclo de vida:

- Mantenibilidad: Evalúa la facilidad para identificar y corregir errores o

realizar ajustes en el sistema.
- Flexibilidad: Indica la capacidad del software para adaptarse a
nuevos requisitos o cambios en el entorno sin necesidad de rehacerlo
completamente.
- Escalabilidad: Mide qué tan bien el software puede manejar un
aumento en la carga de datos o usuarios, o incorporar nuevas
funcionalidades.

● Factores operativos

4
 Relacionados con las condiciones de uso del software y su interacción con
otros sistemas:

- Portabilidad: Determina la capacidad del software para ejecutarse en

distintas plataformas, sistemas operativos o dispositivos.
- Interoperabilidad: Evalúa su capacidad para integrarse y funcionar
correctamente con otros sistemas.
- Seguridad: Mide su protección frente a accesos no autorizados,
pérdida de datos o ataques maliciosos.

5.4 Aseguramiento de la calidad.

Las normas ISO 9000 establecen que el aseguramiento de la calidad consiste en

todas las acciones planificadas y sistemáticas necesarias para generar confianza en
que un producto o servicio cumplirá con los requisitos de calidad establecidos. Para
lograr, mantener y mejorar la calidad, las organizaciones implementan y gestionan
un Sistema de Calidad. Estos sistemas deben diseñarse según las directrices de la
norma ISO 9004 y evaluarse conforme a la norma correspondiente, siendo la ISO
9001 la aplicable al desarrollo de software.

Es importante señalar que los productos no pueden cumplir con la ISO 9001, pero
las organizaciones sí pueden hacerlo. El objetivo es garantizar que el sistema de
calidad empleado asegure que el proceso de desarrollo del software cumple con los
estándares de calidad establecidos.

Un sistema de calidad también puede incluir la necesidad de desarrollar y seguir un

sistema específico para cada proyecto, de manera que se ajuste a las normativas
definidas dentro del mismo. Básicamente, un sistema de calidad se compone de:

5
 ● Programa de garantía de calidad: Documento que define la política de
aseguramiento de calidad alineada con las estrategias y objetivos de la
organización.
● Manuales de normas y procedimientos: Incluyen manuales de
organización, administración, producción, entre otros, que regulan las
actividades relacionadas con la calidad del producto, asignando
responsabilidades y detallando las técnicas aplicables.

5.5 Estándares y métricas de calidad.

Los estándares proporcionan directrices que aseguran que el software cumpla con
requisitos definidos, mientras que las métricas ofrecen una evaluación cuantitativa
del nivel de calidad alcanzado.

Estándares

● ISO/IEC 25010: Proporciona un modelo de calidad que incluye características

como funcionalidad, fiabilidad, usabilidad y mantenibilidad. Por ejemplo, un
sistema bancario debe ser funcional para procesar transacciones, fiable para
evitar interrupciones y seguro para proteger la información.
● IEEE 730: Ofrece pautas para implementar el aseguramiento de la calidad
(QA) mediante pruebas, auditorías y documentación, garantizando que tanto
el producto como los procesos cumplan con los estándares establecidos.
● ISO 9001: Aplicable a la gestión de calidad en general, promueve procesos
eficientes orientados a la satisfacción del cliente. En el ámbito del software,
asegura que los requisitos del cliente se traduzcan en productos efectivos y
con mínimos errores.

Métricas

● Defectos por KLOC (mil líneas de código): Calcula los defectos en función
del tamaño del código. Por ejemplo, si un software tiene 10,000 líneas de
código y se detectan 50 errores, la métrica sería de 5 defectos por KLOC.
● Cobertura de pruebas: Mide el porcentaje de código que se ejecuta durante
las pruebas. Por ejemplo, si de 1,000 líneas de código se prueban 800, la
cobertura es del 80%.
● MTBF (Tiempo medio entre fallos): Evalúa la fiabilidad midiendo el tiempo
promedio entre fallos. Si un sistema opera durante 1,000 horas y experimenta
5 fallos, su MTBF será de 200 horas.
● MTTR (Tiempo medio de reparación): Indica el tiempo promedio necesario
para resolver fallos. Por ejemplo, si reparar 4 fallos toma un total de 8 horas,
el MTTR será de 2 horas.

6
 5.6 Modelos de madurez.
El nivel en que una organización o una unidad organizacional adopta, asimila e implementa
buenas prácticas en la gestión de proyectos, programas y portafolios se denomina madurez
en la gestión de proyectos.

Este nivel de madurez puede evaluarse mediante modelos de madurez. Un modelo de

madurez es un conjunto estructurado de elementos (como buenas prácticas, herramientas
de medición, criterios de análisis, etc.) que permite identificar las capacidades existentes en
la gestión de proyectos dentro de la organización, compararlas con estándares
establecidos, detectar áreas de mejora y definir procesos para fomentar la mejora continua.

El objetivo principal de estos modelos es promover la mejora continua en los procesos de

desarrollo, garantizando que el software entregado cumpla con los requisitos técnicos y
comerciales, al mismo tiempo que se reducen los riesgos asociados.

5.6.1 Enfoque de procesos.

Estándar internacional que ofrece un marco para la evaluación de procesos. Fue
iniciado en 1991 como el proyecto SPICE (Software Process Improvement and
Capability dEtermination). La versión de Reporte Técnico fue aceptada y publicada
en 1998, enfocada únicamente en procesos de software. En el transcurso de su
desarrollo ha evolucionado, de ser un modelo de referencia de buenas prácticas de
software, para convertirse en un marco de trabajo para evaluación de múltiples
modelos (de software o no).

7
Este enfoque asegura que el software de calidad es un resultado directo de
procesos eficientes y controlados. Implica:

● Documentar cada etapa del desarrollo.

● Identificar cuellos de botella o ineficiencias.
● Mejorar continuamente los procesos.

5.6.2 PSP y TSP.

Personal Software Process (PSP) es un proceso diseñado para ayudar a los
ingenieros de software a controlar, manejar y mejorar su trabajo. PSP está basado
en una motivación: La calidad de software depende del trabajo de cada uno de los
ingenieros de software. Debido a que los costos de personal constituyen 70% del
costo del desarrollo de software, las capacidades y hábitos de trabajo de los
ingenieros determinan en gran manera los resultados del desarrollo de software.
Basado en prácticas encontradas en CMM, el PSP puede ser usado por ingenieros
para estructurar y disciplinar el desarrollo de software. El ingeniero de software
podrá planear mejor el trabajo, conocer con precisión el desempeño, medir la
calidad de productos, y mejorar las técnicas.

Team Software Process (TSP) es un marco para el desarrollo de software que pone
igual énfasis en el proceso, producto y trabajo en equipo. Al igual que PSP, TSP fue
propuesto por Watts Humphrey.
TSP se basa en PSP, y se fundamenta en que el software, en su mayoría, es
desarrollado por equipos, por lo que los ingenieros de software deben primero saber
controlar su trabajo, y después saber trabajar en equipo. TSP le enseña a los
ingenieros a construir equipos autodirigidos y desempeñarse como un miembro
efectivo del equipo. También muestra a los administradores como guiar y soportar
estos equipos.

8
 5.6.3 SPICE.

La norma SPICE establece requisitos para la evaluación de procesos y modelos de

evaluación, con el objetivo de que estos requisitos puedan aplicarse en cualquier
modelo de evaluación dentro de una organización.

En términos generales, los requisitos para la evaluación de procesos incluyen:

● Evaluación de procesos.
● Mejora de procesos.
● Evaluación de la capacidad y/o madurez de los procesos.

Además, la norma SPICE también establece requisitos específicos para la

evaluación de procesos en las fases del ciclo de vida del software, conforme a lo
definido en la norma ISO/IEC 12207, así como para la evaluación de procesos en
las fases del ciclo de vida del sistema según el estándar ISO/IEC 15288.

Asimismo, la norma SPICE incluye requisitos que pueden ser utilizados para evaluar
procesos relacionados con el desarrollo de servicios TIC, tal como se define en la
norma ISO/IEC 20000.

9
5.6.4 CMMI.
Integración de modelos de madurez de capacidades o Capability Maturity Model
Integration (CMMI) es un modelo para la mejora y evaluación de procesos para el
desarrollo, mantenimiento y operación de sistemas de software.

En lugar de niveles de madurez, puede obtener los niveles de capacidad en cada

una de las Áreas de Proceso, obteniendo el "Perfil de Capacidad" de la
Organización.
Nivel 1: No Confiable- Ambiente impredecible donde las organizaciones no
tienen actividades de control y no están diseñadas.

Nivel 2: Informal- Las actividades de control existen pero no se ponen en

practica. Los controles dependen básicamente de las personas. No hay un
entrenamiento formal ni comunicación de las actividades de control.

Nivel 3: estandarizado- Las actividades de control existen y están diseñadas,

han sido documentadas y comunicadas a los empleados, las desviaciones de
las actividades de control probablemente no se detecten.

Nivel 4: Monitoreado- Se utilizan herramientas en una forma limitada para

soportar las actividades de control.

Nivel 5: Optimizado- Es una estructura integrada de control interno con un

monitoreo en tiempo real por la gerencia, así como mejoras continuas-auto
control, se encuentran cambios más rápidos al momento de detectar errores
en los manejos de las actividades o en las personas.

10
5.6.5 MoProSoft.
El esquema MoProSoft permite a las pequeñas y medianas empresas que
desarrollan software, demostrar la capacidad de sus procesos y, con esto, hacerlas
más competitivas, a fin de que tengan mayores probabilidades de permanecer en el
mercado.
Se trata de un estándar enfocado hacia una de las estrategias del Programa de
Software (ProSoft) de la Secretaría de Economía, relativa a “alcanzar niveles
internacionales de capacidad de procesos” por parte de las pequeñas y medianas
empresas mexicanas desarrolladoras de software.

11
Referencias.
● FUNDAMENTOS DE INGENIERÍA DE SOFTWARE. (s/f). Blogspot.com. Recuperado el 22

de noviembre de 2024, de https://andoniandresperezdominguezfis.blogspot.com/

● (S/f). Normas-iso.com. Recuperado el 22 de noviembre de 2024, de https://www.normas-

iso.com/iso-iec-15504-spice/

12