EL MODELO DE MCCALL COMO APLICACIÓN DE LA CALIDAD A LA REVISIÓN DEL SOFTWARE

DE GESTIÓN EMPRESARIAL

1. El modelo de McCall.

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:
Puntos De Factor Criterios
Vista O Ejes
OPERACIÓN Facilidad de uso - Facilidad de operación: Atributos del software que
DEL determinan la facilidad de operación del software.
PRODUCTO - 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.
Integridad - 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.
Corrección - 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.
OPERACIÓN Fiabilidad - Precisión: Atributos del software que proporcionan el grado
DEL de precisión requerido en los cálculos y los resultados.
PRODUCTO - Consistencia.
- 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 - 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.
REVISION Facilidad de - Modularidad.
DEL mantenimiento - Simplicidad.
PRODUCTO - Consistencia.
- 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.
Facilidad de - Modularidad.
prueba - Simplicidad.
- Auto descripción.
- 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.
Flexibilidad - Auto descripción.
- 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.
- Modularidad.
Reusabilidad - Auto descripción.
- Generalidad.
- Modularidad.
-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.
Interoperabilidad - Modularidad.
- 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.
Portabilidad - Auto descripción.
- Modularidad.
-Independencia entre sistema y software.
- Independencia del hardware.

2. Cómo emplear el modelo de mccall.

Antes de comenzar a utilizar el modelo de McCall hay que seguir las siguientes pautas:

1. Se aceptan los factores, criterios y métricas que propone el modelo.

2. Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas.
 3. Se selecciona un subconjunto de factores de calidad sobre los que aplicar los requisitos de
calidad establecidos para el proyecto.

Al comienzo del proyecto habrá que especificar los requisitos de calidad del producto software,
para lo cual se seleccionarán los aspectos inherentes a la calidad deseada del producto, teniendo
que considerarse para ello:
 Las características particulares del propio producto que se está diseñando: por ejemplo, su ciclo
de vida que si se espera que sea largo implicará un mayor énfasis en la facilidad de
mantenimiento y la flexibilidad, o bien si el sistema en desarrollo está destinado a un entorno
donde el hardware evoluciona rápidamente implicará como requisito su portabilidad, ...
 La relación calidad-precio, que puede evaluarse a través del coste de cada factor de calidad
frente al beneficio que proporciona. La siguiente tabla muestra la relación calidad-precio para
cada factor considerado:

Factor Beneficio / coste

Corrección alto
Fiabilidad alto
Eficiencia bajo
Integridad bajo
Facilidad de uso medio
Facilidad de mantenimiento alto
Facilidad de prueba alto
Flexibilidad medio
Portabilidad medio
Reusabilidad medio
Interoperabilidad bajo

 La determinación de las etapas del ciclo de vida donde es necesario evaluar cada factor de
calidad para conocer en cuales se dejan sentir más los efectos de una calidad pobre con respecto
a cada uno de los factores.
 Las propias interrelaciones entre los factores debido a que algunos factores pueden entrar
en conflicto entre sí: por ejemplo, la eficiencia plantea conflictos prácticamente con todos los
demás factores de calidad. La interacción entre los diversos factores a evaluar queda reflejada
en la tabla I que indica la dependencia entre los factores de McCall.

También habrá que establecer valores deseables para los criterios, para lo cual se emplearán
datos históricos, el promedio en la industria, .... y con ellos se concretarán los valores finales y
otros intermedios o predictivos en cada período de medición durante el desarrollo, así como
unos valores mínimos aceptables. La explicación para cualquier selección o decisión deberá ser
adecuadamente documentada.
En la fase de desarrollo será necesario implementar las métricas elegidas, analizar sus resultados
y tomar medidas correctivas cuando los valores obtenidos estén por debajo de los mínimos
aceptables.
Una vez finalizado el proyecto será necesario contrastar las medidas predictivas utilizadas y
comprobar si, en efecto, se pueden tomar como indicadores de los valores finales.
3. Conclusiones.
Como se ha visto a lo largo de esta exposición, hoy día se comienza a imponer la obligación de
normas de calidad del software donde un fallo en la información, o en el tratamiento de ésta
puede llevar a fallos catastróficos y de consecuencias imprevisibles. Por ello las organizaciones
están exigiendo controles de calidad más rigurosos en la confección de su software.

EL MODELO COCOMO PARA ESTIMAR COSTES EN UN PROYECTO DE SOFTWARE

COCOMO
El Modelo Constructivo de Costos (o COCOMO, por su acrónimo del
inglés COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para
estimación de costos de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle
y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del
software: básico, intermedio y detallado.
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los
80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall,
1981).

Inconvenientes

 Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los
recursos necesarios para realizarlas.
 Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el
código fuente.
 Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden
ser "vistos" de distinta manera por distintos analistas que usen el método.
 Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no
la productividad.
 La medición por líneas de código no es válida para orientación a objetos.
 Utilizar este modelo puede resultar un poco complicado, en comparación con otros
métodos (que también sólo estiman).

1. Introducción
El Modelo Constructivo de Costes (Constructive Cost Model) fue desarrollado por B. W. Boehm
a finales de los 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software
Engineering Economics" (Prentice-Hall, 1981). COCOMO es una jerarquía de modelos de
estimación de costes software que incluye submodelos básico, intermedio y detallado.

Las ecuaciones de estimación del esfuerzo de desarrollo tienen la

forma
con
• S el número de miles de líneas de código fuente
• m(X) es un multiplicador que depende de 15 atributos
• en la siguiente tabla se muestran los coeficientes para los diferentes modos

Básico Intermedio
Modo ai bi ai bi
Orgánico 2.4 1.05 3.2 1.05
Semiencajado 3.0 1.12 3.0 1.12
Empotrado 3.6 1.2 2.8 1.2

2. Modelo Básico
Este modelo trata de estimar, de una manera rápida y más o menos burda, la mayoría de
proyectos pequeños y medianos. Se consideran tres modos de desarrollo en este modelo:
orgánico, semiencajado y empotrado.

2.1. Modo orgánico.

En este modo, un pequeño grupo de programadores experimentados desarrollan
software en un entorno familiar. El tamaño del software varía de unos pocos miles de líneas
(tamaño pequeño) a unas decenas de miles de líneas (medio), mientras que en los otros dos
modos el tamaño varía de pequeño a muy grandes (varios cientos de miles de líneas). En este
modo, al igual que en los otros, el coste se incrementa a medida que el tamaño lo hace, y el
tiempo de desarrollo se alarga.
Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de
desarrollo. El coste es
Km = 2.4 Sk1.05
donde Km se expresa en personas-mes y Sk es el tamaño expresado en miles de líneas de
código fuente. El tiempo de desarrollo se da por
td = 2.5 Km0.38
donde Km se obtiene de la ecuación anterior y td es el tiempo de desarrollo en meses.
Estas ecuaciones se han obtenido por medio de ajustes de curvas realizado por Boehm en TRW
sobre 63 proyectos.

2.2. Modo Empotrado.

En este modo, el proyecto tiene unas fuertes restricciones, que pueden estar relacionadas
con el procesador y la interface hardware. El problema a resolver es único y es difícil basarse en
la experiencia, puesto que puede no haberla.
Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo
orgánico, pero con diferentes constantes. Así, el coste se da por
Km = 3.6 Sk1.20
y el tiempo de desarrollo por
td = 2.5 Km0.32

2.3. Modo Semiencajado.

Es un modo intermedio entre los dos anteriores. Dependiendo del problema, el grupo
puede incluir una mezcla de personas experimentadas y no experimentadas.
Las ecuaciones son
Km = 3.0 Sk1.12
y el tiempo de desarrollo por
td = 2.5 Km0.35.

2.4. Notas al Modelo Básico

Se puede observar que a medida que aumenta la complejidad del proyecto, las
constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal.
Hay que utilizar con mucho cuidado el modelo básico puesto que se obvian muchas
características del entorno.

3. Modelo Intermedio
En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de
trabajo. Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real,
incrementando la precisión de la estimación.

3.1. Ecuaciones nominales de coste.

Para cada modo de desarrollo, los 15 atributos del coste intervienen como
multiplicadores en el coste nominal, Kn, para producir el coste ajustado.
Las ecuaciones nominales de coste para el modelo intermedio son
modo orgánico Kn = 3.2 Sk1.05
modo semiencajado Kn = 3.0 Sk1.12
modo empotrado Kn = 2.8 Sk1.20
Notemos que:
 • los exponentes son los mismos que los del modelo básico, confirmando el papel que
representa el tamaño;
• los coeficientes de los modos orgánico y empotrado han cambiado, para mantener el
equilibrio alrededor del semiencajado con respecto al efecto multiplicador de los atributos de
coste.

3.2. Atributos de coste.

Estos atributos tratan de capturar el impacto del entorno del proyecto en el coste de
desarrollo. De un análisis estadístico de más de 100 factores que influencian el coste, Boehm
retuvo 15 de ellos para COCOMO.
Estos atributos se agrupan en cuatro categorías: atributos del producto, atributos del
ordenador, atributos del personal y atributos del proyecto.
(1) Atributos del producto
• RELY: garantía de funcionamiento requerida al software
• DATA: tamaño de la base de datos
• CPLX: complejidad del producto
(2) Atributos del ordenador
• TIME: restricción de tiempo de ejecución
• STOR: restricción del almacenamiento principal
• VIRT: volatilidad de la máquina virtual
• TURN: tiempo de respuesta del ordenador
(3) Atributos del personal
• ACAP: capacidad del analista
• AEXP: experiencia en la aplicación
• PCAP: capacidad del programador
• VEXP: experiencia en máquina virtual
• LEXP: experiencia en lenguaje de programación
(4) Atributos del proyecto
• MODP: prácticas de programación modernas
• TOOL: utilización de herramientas software
• SCED: plan de desarrollo requerido.
Cada atributo se cuantifica para un entorno de proyecto. La escala es
muy bajo -- bajo -- nominal -- alto -- muy alto -- extremadamente alto.
En la tabla se muestran los valores del multiplicador para cada uno de los 15 atributos.
Estos 15 valores se multiplican al Kn, y nos proporciona el esfuerzo ajustado al entorno.

3.3. Significado de los atributos.

A. RELY
Indica las posibles consecuencias para el usuario en el caso que todavía existan defectos
en el producto. Una puntuación 'muy baja' indica que solamente hace falta eliminar los defectos
sin ninguna otra consecuencia.
"very low": el efecto de un fallo del software simplemente trae como consecuencia la
inconveniencia de corregir el fallo
"low": el efecto de un fallo software es una pérdida fácilmente recuperable para los
usuarios
"nominal": el efecto es una moderada pérdida para los usuarios, pero es una situación de
la que se puede salir sin excesiva dificultad
"high": el efecto es una gran pérdida financiera o una inconveniencia masiva humana
"very high": el efecto es una pérdida de vidas humanas.
B. DATA
 Indica el tamaño de la base de datos a desarrollar en relación con el tamaño del programa.
Tenemos cuatro segmentos con la razón 10-100-1000, que determinan las puntuaciones de
'bajo' a 'muy alto'.
Se define por el cociente

donde D es la cantidad de datos a ser articulada y almacenada en memoria secundaria (cintas,

discos, etc.) hasta el tiempo de entrega del producto software.
C. CPLX
Indica la complejidad de cada módulo y se utiliza para determinar la complejidad
compuesta del sistema. Entonces la puntuación puede variar de 'muy bajo' si el módulo está
compuesto de expresiones matemáticas simples a 'extremadamente alto' para módulos que
utilizan muchos recursos de planificación.
D. TIME
Siempre será más exigente para un programador escribir un programa que tiene una
restricción en el tiempo de ejecución. Esta puntuación se expresa en el porcentaje de tiempo de
ejecución disponible. Es 'nominal' cuando el porcentaje es el 50%, y 'extremadamente alto'
cuando la restricción es del 95%.
E. STOR
Se espera que un cierto porcentaje del almacenamiento principal sea utilizado por el
programa. El esfuerzo de programación se incremente si el programa tiene que correr en un
volumen menor del almacenamiento principal. STOR captura este esfuerzo extra de 'nominal'
cuando la reducción del almacenamiento principal es del 50% a 'extremadamente alto' cuando
la reducción es del 95%.
F. VIRT
Durante el desarrollo del software la máquina (hard y soft) en la que el programa se va a
desarrollar puede sufrir algunos cambios. VIRT lo refleja desde 'bajo' a 'muy alto'.
G. TURN
Cuantifica el tiempo de respuesta del ordenador desde el punto de vista del programador.
Cuanto mayor sea el tiempo de respuesta, más alto será el esfuerzo humano. TURN puede variar
desde 'bajo' para un sistema interactivo a 'muy alto', cuando el tiempo medio de respuesta es
de más de 12 horas.
H. ACAP
La capacidad del grupo de analistas, en términos de habilidad de análisis, eficiencia y
capacidad para cooperar tiene un impacto significativo en el esfuerzo humano. Cuanto más
capaz sea el grupo, menos esfuerzo será necesario. ACAP puede variar desde 'muy bajo' a 'muy
alto'.
I. AEXP
La experiencia del grupo en una aplicación similar tiene una gran influencia en el esfuerzo.
Puede variar desde 'muy bajo' (menos de cuatro meses de experiencia) a 'muy alto' (mayor de
12 años de experiencia).
"very low": < 4 meses experiencia media
"low": 1 año de experiencia media
"nominal": 3 años de experiencia media
"high": 6 años de experiencia media
"very high": > 12 años, o reimplementación de un subsistema
J. PCAP
La cuantificación es similar a la de ACAP, pero en este caso relacionado con los
programadores. Se aplica a los programadores como grupo, pero no a los programadores
individuales.
K. VEXP
 Cuanto mayor sea la experiencia del grupo de programación con el procesador, menor
será el esfuerzo necesario. VEXP puede variar desde 'muy bajo', cuando la experiencia es menor
de un mes, a 'alto' cuando esta experiencia es mayor de 3 años.
"very low": < 1 mes experiencia media
"low": 4 meses
"nominal": 1 año
"high": > 3 años
L. LEXP
Un grupo de programadores con amplia experiencia en un lenguaje determinado
programará de una manera mucho más segura, generando un menor número de defectos y de
requerimientos humanos. Puede variar desde 'muy bajo' a 'alto' para un grupo de un mes a tres
años de experiencia, respectivamente.
"very low": < 1 mes experiencia media
"low": 4 meses de experiencia media
"nominal": 1 año de experiencia media
"high": > 3 años
M. MODP
Utilización de modernas prácticas de programación. Varía de 'muy bajo' a 'muy alto'. Estas
prácticas incluyen, por ejemplo, programación estructurada y desarrollo 'top-down'.
"very low": no se utilizan prácticas modernas de programación -PMP-.
"low": uso experimental de algunas PMP
"nominal": experiencia razonable en el uso de algunas PMP
"high": experiencia razonable en gran parte de PMP
"very high": uso habitual de PMP

N. TOOL
El uso adecuado de herramientas software es un multiplicador de la productividad. La
puntuación de TOOL varía desde 'muy bajo' cuando sólo se utilizan herramientas básicas, a 'muy
alto' cuando se utilizan herramientas específicas.
O. SCED
El tiempo nominal de desarrollo, tal como se define en el modo básico, es el plazo que
requiere menor esfuerzo humano. Cualquier apresuramiento ('muy bajo') o retraso ('muy alto')
demandarán más esfuerzo.

3.4. Notas al modelo Intermedio.

Este modelo proporciona una manera potente de capturar la influencia del entorno en el
proyecto.

4. Modelo Detallado
Este modelo puede procesar todas las características del proyecto para construir una
estimación. Introduce dos características principales
(1) Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven más afectadas
que otras por los atributos. El modelo detallado proporciona un conjunto de multiplicadores de
esfuerzo para cada atributo. Esto ayuda a determinar la asignación del personal para cada fase
del proyecto.
(2) Jerarquía del producto a tres niveles. Se definen tres niveles de producto. Estos son
módulo, subsistema y sistema. La cuantificación se realiza al nivel apropiado, esto es, al nivel al
que es más susceptible la variación.

4.1. Estimación del esfuerzo.

A. Fases de desarrollo
 El desarrollo del software se lleva a cabo a través de cuatro fases consecutivas:
requerimientos/planes, diseño del producto, programación y prueba/integración.
Requerimientos/planes. Esta es la primera fase del ciclo de desarrollo. Se analiza el
requerimiento, se muestra un Plan de Producto y se genera una especificación completa del
producto. Esta fase consume del 6% al 8% del esfuerzo nominal Kn, y dura del 10% al 40% del
tiempo nominal de desarrollo td. Estos porcentajes dependen del modo y del tamaño (de 2000
LOC a 512000 LOC).
Diseño del producto. La segunda fase del ciclo de desarrollo COCOMO se preocupa de la
determinación de la arquitectura del producto y de las especificaciones de los subsistemas. Esta
fase requiere del 16% al 18% del esfuerzo nominal Kn, y puede durar del 19% al 38% del tiempo
nominal de desarrollo td.
Programación. La tercera fase del ciclo de desarrollo COCOMO se subdivide en dos subfases:
diseño detallado y prueba del código. Esta fase requiere del 48% al 68% del esfuerzo nominal Kn,
y dura del 24% Al 64% del tiempo nominal de desarrollo.
Prueba/Integración. Esta última fase consiste principalmente en unir las diferentes unidades ya
probadas. Se utiliza del 16% al 34% del coste nominal Kn y dura del 18% al 34% del td.
B. Principio de estimación del esfuerzo.
B.1. Tamaño equivalente. Como parte del software puede haber sido ya desarrollado, no
se requiere entonces un desarrollo completo. En tales casos se estiman las partes de diseño
(D%), código (C%) e integración (I%) a ser modificadas. Se calcula un factor de ajuste A
A = 0.4 D + 0.3 C + 0.3 I
El tamaño equivalente, Sequ es
Sequ = (S · A) / 100.
B.2. Cálculo del esfuerzo. El tamaño equivalente se calcula para cada módulo. El esfuerzo
asignado al desarrollo de cada módulo se obtiene entonces a través de:
(1) seleccionar los valores apropiados de los atributos de coste para cada fase
(2) multiplicar los atributos de coste para cada módulo y fase, obteniendo un conjunto de
4 multiplicadores globales
(3) multiplicar los atributos globales por el esfuerzo nominal en cada fase y sumarlos para
obtener el esfuerzo total estimado.

5. Conclusiones sobre COCOMO.

Es uno de los modelos más documentados en la actualidad y es muy fácil de utilizar. Es
correcto con referencia a los 63 proyectos utilizados, aunque de ello no se debe desprender que
deba ser válido siempre. Una preocupación es la adaptación de las ecuaciones exponenciales a
organizaciones específicas, cosa que no parece inmediatamente fácil.

6. Validación independiente del modelo COCOMO (Conte et al.)

El rendimiento de COCOMO en su propia base de datos se indica en la tabla 6.13. El
COCOMO Básico no funciona bien en su propia base de datos. El Intermedio lo hace bastante
mejor.
Es muy difícil evaluar COCOMO Intermedio en otras bases de datos debido a que hay que
proporcionar muchos parámetros. El modelo Básico ha sido evaluado según indica la tabla 6.15,
dando unos resultados pobres (quizá debido a la falta de datos). A continuación, se indican unas
fórmulas mejoradas sobre las originales