UNIVERSIDAD ABC

ASEGURAMIENTO DE CALIDADDEL DESARROLLO DE SOFTWARE

Sección A

MODELOS PARA CLASIFICAR ATRIBUTOS

DE CALIDAD DE SOFTWARE
INVESTIGACIÓN
 MODELO CAPABILITY MATURITY MODEL INTEGRATION
-CMMI-

Hoy en día, el CMMI es un modelo importante para la mejora de procesos y el

desarrollo de software. Las empresas que lo implementan experimentan una mayor
productividad y calidad, una mejor duración de ciclos de vida y presupuestos más
precisos y predecibles.

El Modelo de Madurez de Capacidad Integrado

(CMMI, por sus siglas en inglés), es una
expansión del Modelo de Madurez (CMM).
Es un modelo en donde se establecen las
mejores prácticas de la industria tecnológica,
que rigen para el desarrollo y mantenimiento
de software, como también para la obtención y
operación de productos y servicios. Es una
herramienta que se utiliza para la mejora de
procesos, mejorar la calidad y para fomentar la
eficiencia, reduciendo así los riesgos en el proceso de
desarrollo. Este método no solo se aplica en el desarrollo de software, también es
utilizado en los procesos de hardware y desarrollo de servicios en cualquier industria.
El modelo CMMI cuenta también con unas fases o niveles de desarrollo, en los que
las empresas se encasillan de acuerdo a los procesos realizados y los objetivos
cumplidos, aquí se califica la madurez de los procesos implementados en el
desarrollo del software y el cumplimiento de estos objetivos aporta los fundamentos
necesarios para aplicar efectivamente los procesos en el siguiente nivel. Así se
dividen:

Nivel 1 – Inicial: El proceso es informal = Menor calidad y alto riesgo

Nivel 2 – Gestionado: Nivel básico para la gestión de proyectos = Baja calidad y

alto riesgo

Nivel 3 – Definido: Estandarización de procesos = Calidad media y riesgo medio

Nivel 4 – Cuantitativamente gestionado = Mayor calidad y menor riesgo

Nivel 5 – Optimizar: Mejora continua de los procesos = Máxima calidad y menor

riesgo

Aplicar este modelo en el desarrollo de software es importante puesto que permite

optimizar algunos procesos de negocio, desarrollar productos con calidad para
satisfacer las necesidades del cliente y ayuda a cumplir de forma completa con los
requerimientos de la norma ISO y crear una cultura de mejora continua.

Adquirir un software dirigido bajo este modelo implica también unas ventajas, ya
que la utilización de buenas practicas en el desarrollo de software se traduce en:

- Comunicación efectiva entre las partes, tanto entre los integrantes del equipo de
desarrollo como con el cliente, este último participa activamente en el proceso, por
lo que siempre esta informado sobre el estado de su proyecto y sus
responsabilidades en él.

- Software más completos, en cuanto a estructura ya que el modelo permite realizar

acciones como una toma acertada de requisitos del cliente, capacitación del equipo
de trabajo, aplicación de pruebas e inspección y buenas prácticas de ingeniería de
software.

- Software entregados a tiempo, pues el modelo mejora las predicciones de entrega

del producto al cliente, esto permite que se le manifieste al cliente una fecha de
entrega que será cumplirá en la mayoría de los casos.

- Software con menor cantidad de defectos, pues son resueltos en las fases
tempranas de desarrollo.
Por último, cabe resaltar que este modelo es de gran beneficio para obtener ventajas
competitivas, tanto para las empresas encargadas del desarrollo del producto, como
para quien lo recibe, pues un software hecho con buenas prácticas, es un software
el cual pasó por procesos efectivos, que seguramente serán de la mejor calidad,
ofreciendo ventajas en su implementación ya que será más fácil de manipular, que
presentará menos fallas en su estructura y procedimientos y que ofrecerá un mayor
retorno de la inversión

VENTAJAS DESVENTAJAS
(CMMI) (CMMI)
Reducción del costo de desarrollo
Localización y resolución de El problema de CMMI es su falta de
defectos adecuación al enfoque al servicio
Mejora en fiabilidad de la que está experimentando el sector
planificación en términos de de las TIC (procesos de desarrollo
dedicación y de calendario de productos de software) en todas
Aumento de la productividad sus líneas de actividad, así como el
Reducción de los trabajos alto esfuerzo de implantación que
derivados de correcciones tras la exige
pruebas
Aumento de la efectividad sobre la El proceso de evaluación es muy
planificación realizada costoso en tiempo y esfuerzo
La complejidad de la evaluación
Mejora en la calidad de producto puede atentar contra la definición
de objetos concretos de madurez
Reducción del númerode defectos
y detección en las fases tempranas
de su ciclo de vida
Mejora de la imagen de marca
Se puede aplicar a más de una
disciplina
Mejor atención a las áreas de
ingeniería
Mejor visibilidad de los proyectos
Mejor comunicación de los
participantes de cada proyecto
Mejora la calidad del producto
Se establece más conocimiento
sobre la organización
Los clientes viven más informados
 Modelo de Calidad BOEHM

El modelo de calidad denominado de Boehm, que fue

propuesto por Barry Boehm en el año de 1978 es una
herramienta que guía a las organizaciones a una mejora
continua y a la competitividad, dentro de su diseño.
Presenta una jerarquía de características cada una de
las cuales contribuye a la calidad global y que además
abarca necesidades y expectativas de los usuarios. Siempre en busca de la calidad
de los productos que puede medirse como una comparación de sus características
y atributos.
Este modelo define la calidad en términos de tributos cualitativos y métricas para
realizar las medidas y se centra en sus características operativas, su capacidad
para medir los cambios, su adaptabilidad a nuevos entornos y la evaluación del
desempeño del hardware entre otros. La calidad del hardware es el grado con el
que un sistema, componente o proceso cumple los requerimientos especificados y
las necesidades y expectativas del cliente o usuario.
Este modelo pretende que el software haga 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. Este bien
diseñado, codificado y sea probado y mantenido fácilmente.
Este modelo presenta una estructura de 3 niveles para las características

✓ Características de alto nivel, que representan requerimientos generales de

uso.
✓ Características de nivel intermedio, que son los factores de calidad de
Boehm
✓ Características primitivas, asociadas a uno o dos métricas de calidad.
Cada una de estas características contribuye al nivel general de calidad. A
continuación, observamos un mapa conceptual de las características de cada nivel.
Características de alto nivel
✓ Utilidad, cuan (usable, confiable, eficiente) es el producto en sí mismo.
✓ Mantenimiento, cuan fácil es modificarlo, entenderlo y re-testearlo.
✓ Utilidad general, si puede seguir usándose si se cambia el ambiente.
Características de nivel intermedio
✓ 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
Eficiencia
✓ Accesibilidad
✓ Eficiencia de uso de dispositivos
Usabilidad
✓ Robustez/Integridad
✓ Accesibilidad
✓ Comunicación
Testeabilidad
✓ Comunicación
✓ Auto descripción
✓ Estructuración
Entendibilidad
✓ Consistencia
✓ Estructuración
✓ Concisidad
✓ Legibilidad
Modificabilidad
✓ Estructuración
✓ Aumentabilidad
 VENTAJAS
Integra el desarrollo del software
con el mantenimiento
Usa los mejores factores o
elementos de otros modelos
Sus características primitivas son
varias y orientadas a diferentes
niveles
DESVENTAJAS
Genera mucho tiempo de análisis y por
ende eleva los costos de desarrollo
Su desarrollo exigen al 100% de la
secuencia y los protocolos

Modelo de Calidad Software ISO/IEC 25000

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.

La familia ISO/IEC 25000 es el resultado de la evolución de otras normas

anteriores, especialmente de las normas ISO/IEC 9126, que describe las
particularidades de un modelo de calidad del producto software, e ISO/IEC
14598, que abordaba el proceso de evaluación de productos software. Esta
familia de normas ISO/IEC 25000 se encuentra compuesta por cinco
divisiones.
ISO/IEC 2500n – División de Gestión de Calidad
Las normas que forman este apartado definen todos los modelos, términos
y definiciones comunes referenciados por todas las otras normas de la
familia 25000. Actualmente esta división se encuentra formada por:

ISO/IEC 25000 - Guide to SQuaRE

Contiene el modelo de la arquitectura de SQuaRE, la terminología de la
familia, un resumen de las partes, los usuarios previstos y las partes
asociadas, así como los modelos de referencia.

ISO/IEC 25001 - Planning and Management

Establece los requisitos y orientaciones para gestionar la evaluación y
especificación de los requisitos del producto software.

ISO/IEC 2501n – División de Modelo de Calidad

Las normas de este apartado presentan modelos de calidad detallados
incluyendo características para calidad interna, externa y en uso del
producto software. Actualmente esta división se encuentra formada por:

ISO/IEC 25010 - System and software quality models

Describe el modelo de calidad para el producto software y para la calidad en
uso. Esta Norma presenta las características y subcaracterísticas de calidad
frente a las cuales evaluar el producto software.

ISO/IEC 25012 - Data Quality model

Define un modelo general para la calidad de los datos, aplicable a aquellos
datos que se encuentran almacenados de manera estructurada y forman
parte de un Sistema de Información.

ISO/IEC 2502n – División de Medición de Calidad

Estas normas incluyen un modelo de referencia de la medición de la calidad
del producto, definiciones de medidas de calidad (interna, externa y en uso)
y guías prácticas para su aplicación. Actualmente esta división se encuentra
formada por:

ISO/IEC 25020 - Measurement reference model and guide

Presenta una explicación introductoria y un modelo de referencia común a
los elementos de medición de la calidad. También proporciona una guía
para que los usuarios seleccionen o desarrollen y apliquen medidas
propuestas por normas ISO.
ISO/IEC 25021 - Quality measure elements
Define y especifica un conjunto recomendado de métricas base y derivadas
que puedan ser usadas a lo largo de todo el ciclo de vida del desarrollo
software.

ISO/IEC 25022 - Measurement of quality in use

Define específicamente las métricas para realizar la medición de la calidad
en uso del producto.

ISO/IEC 25023 - Measurement of system and software product

quality
Define específicamente las métricas para realizar la medición de la calidad
de productos y sistemas software.

ISO/IEC 25024 - Measurement of data quality

Define específicamente las métricas para realizar la medición de la calidad
de datos.

ISO/IEC 2503n – División de Requisitos de Calidad

Las normas que forman este apartado ayudan a especificar requisitos de
calidad que pueden ser utilizados en el proceso de elicitación de requisitos
de calidad del producto software a desarrollar o como entrada del proceso
de evaluación. Para ello, este apartado se compone de:

ISO/IEC 25030 - Quality requirements

Provee de un conjunto de recomendaciones para realizar la especificación
de los requisitos de calidad del producto software.

ISO/IEC 2504n – División de Evaluación de Calidad

Este apartado incluye normas que proporcionan requisitos,
recomendaciones y guías para llevar a cabo el proceso de evaluación del
producto software. Esta división se encuentra formada por:

ISO/IEC 25040 - Evaluation reference model and guide

Propone un modelo de referencia general para la evaluación, que considera
las entradas al proceso de evaluación, las restricciones y los recursos
necesarios para obtener las correspondientes salidas.
 ISO/IEC 25041 - Evaluation guide for developers, acquirers and
independent evaluators
Describe los requisitos y recomendaciones para la implementación práctica
de la evaluación del producto software desde el punto de vista de los
desarrolladores, de los adquirentes y de los evaluadores independientes.

ISO/IEC 25042 - Evaluation modules

Define lo que la Norma considera un módulo de evaluación y la
documentación, estructura y contenido que se debe utilizar a la hora de
definir uno de estos módulos.

ISO/IEC 25045 - Evaluation module for recoverability

Define un módulo para la evaluación de la subcaracterística Recuperabilidad
(Recoverability).

La división de extensión de SQuaRE (ISO/IEC 25050 a ISO/IEC 25099) se

reserva para normas o informes técnicos que aborden dominios de
aplicación específicos o que puedan ser utilizados para complementar otras
normas de la familia SQuaRE.

VENTAJAS
DETECTA LO OBJETIVOS DEL
SOFTWARE CON LAS NECESIDADES
REALES Y EFECTIVAS QUE SOLICITA EL
CLIENTE FINAL
EVITA INEFICIENCIA Y MAXIMIZA LA
RENTABILIDAD Y CALIDAD DEL
PRODUCTO DE SOFTWARE
CUMPLE LOS REQUISITOS
CONTRACTUALES Y DEMUESTRA 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
DESVENTAJAS
NO ESTABLECE LOS NIVELES DE
CALIDAD DESEABLES PARA CADA
PROYECTO
NO MENCIONA UN NÚMERO DE
REFERENCIA A LOGRAR, O EL UMBRAL
QUE DEBE CUMPLIR UNA MÉTRICA
SERÍA IRREAL FIJAR UN VALOR, O
VALORES, ÚNICOS DE REFERENCIA
PARA TODA LA INDUSTRIA