factores de calidad mccall

8/2/2019 Factores de Calidad McCall

1/7

a54 analesde mecnica y electricidad

Introduccin

La aparicin en la prensa defrases como El desarrollo

del software se ha convertido

en un tema crtico para las

modernas organizaciones, y

por tanto para toda la socie-

dad (Fitzgerald & OKane,

1999) o Que el desarrollo del

software sea un xito implica

mucho ms que escribir cdi-

go. La mayora de las organi-

zaciones de desarrollo del

software comprenden ahora

que el xito de los procesos

depende de la organizacin yestructura de la empresa, el

control de proyectos y los pro-

cedimientos y estndares soft-

ware (Dutta, Lee, & Van

Wassenhove, 1999) ponen de

relieve la importancia que ac-

tualmente se le da al desarro-

llo del software.

Con el fin de solucionar es-

te problema (que se ha venido

llamando la crisis del software)

surge la disciplina llamada in-

geniera del software que sedefine como (Pressman, 1995):

Establecimiento y uso de

principios de ingeniera robus-

tos, orientados a obtener soft-

ware econmico que sea fiable

y funcione de manera eficiente

sobre mquinas reales.

Una de la reas de trabajo

de la ingeniera del software

que ms auge est teniendo

actualmente es la calidad, aun-

que realmente sea una discipli-na poco extendida. Seleccio-

nando una de las posibles defi-

niciones de (Nistal Rosique,

1999):

Calidaddel software (I)Calidaddel software (I)Los primeros aos de la era informtica se vieron

marcados por el desafo del desarrollo del hardware de

los ordenadores. Este desafo se ha visto superado por

los vertiginosos avances de la microelectrnica. Hoy en

da el principal problema al que nos enfrentamos es la

llamada crisis del software. La causa principal de esta

crisis es el aumento de la complejidad de las

aplicaciones sin la adopcin de los procesos adecuados

de desarrollo que contribuiran a obtener un producto

de mayor calidad y menor coste. En este artculo se van

a presentar cules son esas claves para conseguir un

software de mayor calidad.

Yolanda Gonzlez ArechavalaLicenciada en Informtica por la Universidad del Pas Vasco. Esinvestigadora en Formacin del Instituto de InvestigacinTecnolgica y profesora en el Departamento de SistemasInformticos, ambos de la ETS de Ingeniera de la UP-Co. Estetrabajo ha sido parcialmente financiado con una beca de laAsociacin de Ingenieros del ICAI.

Fernando de Cuadra GarcaDr. Ingeniero Industrial del ICAI. Es Profesor Propio

Agregado de la UPCo, Director de la Escuela TcnicaSuperior de Ingeniera (ICAI) e Investigador del

Instituto de Investigacin.

Art. Calidad del Software 1* 19/10/01 13:30 Pgina 54


2/7

CALIDAD DEL SOFTWARE (I)

a 55analesde mecnica y electricidad

Calidad del Software con-

siste en desarrollar productos

lgicos que, cumpliendo las

normas, satisfagan las necesi-

dades del usuario, los requisi-

tos implcitos (a menudo, no

mencionados) y que tiendan a

cero defectos.

Para conseguir un software

de calidad es necesario realizar

una serie de tareas a lo largo

de todo el proceso de desarro-

llo de la aplicacin. Es lo que

se conoce como la garanta de

calidad del software (SQA:

Software Quality Assuran-

ce). Segn Pressman:

La garanta de calidad delsoftware es un diseo planifi-

cado y sistemtico de acciones

que se requieren para asegurar

la calidad del software

En los siguientes apartados

se van estudiar en primer lugar

los factores que afectan a la

calidad del software. Poste-

riormente, se estudiarn las

tareas relacionadas con la ga-

ranta de calidad del software.

Con esto se contemplar laprimera parte de este artculo.

En la segunda parte se analiza-

rn dos de estas tareas, como

son las mtricas empleadas so-

TABLA 1. FCTORES DE CALIDAD DE MCCALL

Relacionado con

Grado en que un programconsigue los objetivos de la misin encomendada por el

cliente

Probabilidad de operacin libre de fallos de un programa de computadora en un

entorno determinado durante un tiempo especfico

Cantidad de recursos de computadora y de cdigo requeridos por un programa pa-

ra llevar a cabo sus funciones

Grado en que puede controlarse el acceso al software o a los datos, por personal

no autorizado

Esfuerzo requerido para aprender un programa, trabajar con l, preparar su entra-

da e interpretar su salida

Esfuerzo requerido para localizar y arreglar un error en un programa

Esfuerzo requerido para modificar un programa operativo

Esfuerzo requerido para probar un programa de forma que se asegure que realiza

la funcin requerida

Esfuerzo requerido para transferir el programa desde un hardware y/o entorno de

sistemas de software a otro

Grado en que un programa (o partes de un programa) puede reusarse en otras

aplicaciones

Esfuerzo requerido para acoplar un sistema a otro

Aspecto

que trata

Operacin

del Producto

Revisin

del producto

Transicin

del producto

Factor

Calidad

Correccin

Fiabilidad

Eficiencia

Integridad

Facilidad

de uso

Facilidad de

mantenimiento

Flexibilidad

Facilidad

de prueba

Portabilidad

Reusabilidad

Facilidad de

interoperacin



3/7

bre calidad del software y los

estndares que existen en la

actualidad. Como punto final,

se muestran las restriccionesque tienen algunas de las tc-

nicas comentadas en el artcu-

lo para garantizar la calidad del

software.

Factores de Calidad

Segn (Pressman, 1995),

basndose en los estudios

de (McCall, 1977), los facto-

res que afectan a la cal idad

del software se centran entres aspectos importantes de

un producto software: sus ca-

ractersticas operativas, su ca-

pacidad de soportar los cam-

bios (revisin del producto) y

su adaptabilidad a nuevos en-

tornos (o transicin del pro-

ducto). En la Tabla 1 se mues-

tran los factores de cal idad

definidos por McCall. Estos

factores de calidad de McCall,

a pesar de haberse def inido

hace mucho tiempo, conser-

van en gran medida su vigen-cia (salvo para el caso de la

programacin orientada a ob-

jetos).

Es difcil (y en algunos ca-

sos imposible) desarrollar me-

didas directas de los anteriores

factores de calidad. Por tanto,

se define un conjunto de m-

tricas usadas para evaluar los

factores de calidad. Segn de

qu factor se trate, se utiliza-

rn unas determinadas mtri-

cas ponderadas para determi-nar ese factor. Las mtricas

(algunas de ellas medidas sub-

jetivas) que utiliza McCall para

evaluar los distintos factores



TABLA 2. MTRICAS PROPUESTAS POR MCCALL

Mtrica Relacionado con

La facilidad con que se puede comprobar la confor-

midad con los estndares

La precisin de los clculos y del control

El grado en que se usa el ancho de banda, los pro-

tocolos y las interfaces estndar

El grado en que se ha conseguido la total implanta-

cin de las funciones requeridas

Lo compacto que es el programa en trminos de l-

neas de cdigo

El uso de un diseo uniforme y de tcnicas de do-

cumentacin a lo largo de todo el programa

El uso de estructuras de datos y de tipos estndar

a lo largo de todo el programaEl dao que se produce cuando el programa detec-

ta una situacin erronea

El rendimiento en tiempo de ejecucin de un pro-

grama

El grado en que se puede ampliar el diseo arqui-

tectnico, de datos o procedimental

La amplitud de aplicacin potencial de los compo-

nentes del programa

El grado en que el software es independiente del

hardware sobre el que opera

El grado en que el programa muestra su propio fun-

cionamiento e identifica errores que aparecen

La independencia funcional de los componentes delprograma

La facilidad de utilizacin de un programa

La disponibilidad de mecanismos que controlen o

protejan los programas o los datos

El grado en que el cdigo fuente proporciona docu-

mentacin significativa

El grado en que un programa puede ser entendido

sin dificultad

El grado en que el programa es independiente de

caractersticas no estndar del lenguaje de progra-

macin, de las caractersticas del sistema operativo

y de otras restricciones del entorno

La posibilidad de seguir la pista a la representacindel diseo o de los componentes reales del progra-

ma hacia atrs, hacia los requisitos

El grado en que el software ayuda a permitir que

nuevos usuarios empleen el sistema

Facilidad de auditora

Exactitud

Normalizacin de las

comunicaciones

Completitud

Concisin

Consistencia

Estandarizacin

en los datos

Tolerancia de errores

Eficiencia en la

ejecucin

Facilidad de

expansin

Generalidad

Independencia del

hardware

Instrumentacin

Modularidad

Facilidad de operacin

Seguridad

Autodocumentacin

Simplicidad

Independencia del

sistema de software

Facilidad de traza

Formacin



4/7

de calidad se muestran en la

Tabla 2.

Garanta de Calidad

La garanta de calidad del

software comprende una

gran variedad de tareas, aso-

ciadas a siete actividades prin-

cipales:

Mtodos y herramientasde anlisis, diseo ycodificacin

La calidad del software de-

be estar diseada para el pro-

ducto o sistema, no es algo im-

puesto a posteriori. Por esta

razn, la garanta de calidad

del software comienza real-

mente con un conjunto de he-

rramientas y mtodos tcnicos

que ayudan al analista a conse-

guir una especificacin y un di-

seo de alta calidad.

En un proceso de desarro-

llo software, existen una seriede fases que vienen determi-

nadas por las tareas bsicas

que hay que realizar para ob-

tener el producto software.

Se definen distintos ciclos de

vida de acuerdo a la evolucin

del software a lo largo de di-

chas fases. Las fases ms tpi-

cas son:

Requisitos del Sistema:

tambin llamada anlisis de re-

quisitos, especificacin o dise-

o conceptual o diseo de alto

nivel. Segn (Durn Toro, Ber-

nrdez Jimnez, Corchuelo

Gil, & Toro Bonilla, 2000) en(IEEE, 1990) se define:

Requisitos: (a) una condi-

cin o capacidad que un usua-

rio necesita para resolver un

problema o lograr un objetivo.

(b) una condicin o capacidad

que debe tener un sistema o

un componente de un sistema

para satisfacer un contrato,

una norma, especificacin u

otro documento formal. (c)

una representacin en forma

de documento de una condi-cin o capacidad como las ex-

presadas en (a) o (b).

La ingeniera de requisitos se

define como:

Todas las actividades rela-

cionadas con: (a) identificacin

y documentacin de las nece-

sidades del cliente y usuarios,

(b) creacin de un documento

que describe la conducta ex-

terna y las restricciones aso-

ciadas del sistema que satisfardichas necesidades. (c) anlisis

y validacin del documento de

requisitos para asegurar su

consistencia, viabilidad y que

sea completo. (d) evolucin de

las necesidades.

Existen varias propuestas

en cuanto a las actividades que

conlleva la ingeniera de requi-

sitos. Por su claridad, se ha uti-

lizado la presentada en (Durn

Toro et al., 2000), que com-

prende tres actividades princi-

pales: obtencin, anlisis y va-

lidacin. La mayor parte de las

normas y autores asumen queel proceso de obtencin de los

requisitos, su anlisis y valida-

cin es iterativo por naturale-

za, ya que se reconoce que es

prcticamente imposible obte-

ner todos los requisitos y que

stos sean correctos sin tener

que volver atrs en algn mo-

mento del proceso. Las activi-

dades son:

Obtencin (Elicitation1)

de Requisitos: los clientes,

compradores o usuarios delsistema a desarrollar descu-

bren, revelan, articulan y

entienden sus propios requi-

sitos. Los requisitos se ob-

tienen con entrevistas,

cuestionarios, reuniones de

las distintas partes implica-

das y diversas tcnicas cuyo

resultado deben ser los re-

quisitos orientados al clien-

te o tambin l lamados re-

quisitos - C, que sern ana-

lizados en la siguiente acti-

vidad.

Anlisis de requisitos: se de-

be razonar sobre los requisi-

tos-C para comprender me-

jor el problema, detectar

conflictos o inconsistencias,

combinar requisitos relacio-

nados e identificar nuevos

requisitos, normalmente

mediante la construccin de

modelos, en la que podran

participar aquellos clientes y

usuarios con los conoci-



1 El trmino en ingls elicitatin se utiliza en la obtencin de requisitos para definir la actividad realizada por el analista con

el fin de proteger la informacin que de las necesidades del sistema tienen los usuarios finales, los expertos y los clientes.

Adems, esta actividad debe ser capaz de mostrar el conocimiento tcito, aquello que los usuarios no comentan por olvidarlo

o considerarlo obvio.



5/7

mientos apropiados. El pro-

ducto de esta actividad son

los requisitos orientados al

desarrollador o requisitos-D, y en algunas ocasiones,

un prototipo.

En esta fase ya se estn to-

mando decisiones de cmo

hacer el sistema ya que se

realiza una descomposicin

del sistema en subpartes si-

guiendo la tcnica de divi-

de y vencers.

Validacin de requisitos: los

cl ientes y usuarios deben

confirmar que los requisitos-C, una vez analizados, son

vlidos, correctos y comple-

tos, mediante las inspeccio-

nes de los documentos ge-

nerados y mediante la eva-

luacin del prototipo, proce-

so que por lo general

conlleva la obtencin de

nuevos requisitos. Adems

ser necesario validar que

los requisitos -D encajan con

los requisitos -C.

La nomenclatura de los re-quisitos (requisitos-C para los

del cliente y requisitos-D para

los del desarrollador) fue pre-

sentada en (Brackett, 1990) y

est siendo aceptada por al-

gunos autores como (Durn

Toro et al., 2000). La manera

habitual de expresar los re-

quisitos-C es el lenguaje na-

tural, que puede acompaar-

se del uso de plantillas y pa-

trones lingsticos para facili-

tar su uso. La forma de

expresar los requisitos -Dsuele ser mediante un modelo

construido con tcnicas es-

tructuradas (DFD, ERD, etc),

tcnicas orientadas a objetos

(OMT, UML, etc ) o tcni cas

formales..

Dado que diversos estudioshan revelado que el alto ndice

de fracasos en los proyectos

de desarrollo software tiene

como principales causas acti-

vidades relacionadas con los

requisitos (falta de participa-

cin de los usuarios, requisitos

incompletos y frecuentes

cambios de los requisitos ini-

ciales), es lgico que muchos

estudios se basen en esta eta-

pa, por lo que las publicacio-

nes relativas a la ingeniera de

requisitos han sido abundantesen los ltimos aos (por ejem-

plo, los nmeros especiales de

las revistas IEEE Software

Marzo/Abril 1998 o el de

Communications of the

ACM Diciembre 1998 as co-

mo diversos libros). Adems,

existen multitud de mtodos

de modelado en general que se

uti l izan para el modelado de

los requisitos-D. Otro ejemplo

es el proyecto MENHIR: Me-

todologas, Entornos y Nue-

vas Herramientas para la In-geniera de Requisitos (Pro-

yecto de la CICYT TIC 97-

0593-C05-0).

Diseo: tambin llamado di-

seo arquitectural o diseo de

bajo nivel.

Partiendo del modelo de

anlisis de requisitos obtenido

en la fase anterior, se transfor-

ma ste en un conjunto de en-

tes fsicos (hardware) y entes

lgicos (software) inter-rela-cionados entre s que no tie-

nen por qu conservar la mis-

ma estructura que en el mode-

lo inicial.

Cualquier cambio en dicha

estructura con respecto a la

del modelo inicial debe ir

acompaado de las razonesque lo han aconsejado, que

suelen ser ciertas caractersti-

cas que en su momento no se

conoca, o no se tuvieron en

cuenta por ser un aspecto de

mayor nivel de detalle.

Aunque en principio los

requisitos -C afectan princi-

palmente a la fase de anlisis

de requisitos y se utilizan pa-

ra la creacin de los requisitos

-D (que evidentemente influ-

yen directamente en la fasede diseo ), puede darse el

caso de que alguno de los re-

quisitos del c l iente tengan

efecto directo sobre esta fase

de diseo.

Implantacin e Integra-

cin: tambin llamada codifi-

cacin. Consiste en la codifi-

cacin del software utilizando

un lenguaje de programacin

siguiendo la estructura y com-

portamiento determinados en

el diseo.

Revisiones delsoftware que seaplican durantecada paso deldesarrollo delmismo

Una vez que se ha creado

una especificacin y un diseo

de un software, debe garanti-

zarse su calidad. Las revisio-

nes del software son un filtropara el proceso de ingeniera

del software y se aplican en

varios momentos del desarro-

llo. Sirven para detectar fallos





6/7

tanto en el anlisis como en el

diseo y la codif icacin, de

manera que puedan ser elimi-

nados cuanto antes. Es nece-sario partir de la idea de que

todo el mundo comete erro-

res, pero algunos de ellos se le

pasan por alto ms fcilmente

al que los origina que a otras

personas. Los errores cometi-

dos en pasos anteriores se

amplifican en el paso siguien-

te. Segn las estadsticas, las

actividades de diseo introdu-

cen entre el 50 y el 65 por 100

de todos los errores, por lo

que cualquier tcnica que per-

mita detectar los errores enlas fases iniciales del desarro-

llo del software ser de gran

utilidad.

Existen muchos tipos dife-

rentes de revisiones depen-

diendo de qu se revise y el ti-

po de profesional que lo revise.

Una de ellas son las revisiones

tcnicas formales o inspeccio-

nes, llevadas a cabo por inge-

nieros del software. Las revi-

siones tcnicas formales son el

f i ltro ms efectivo desde elpunto de vista de la garanta

del software, ya que detectan

el 75% de los errores cometi-

dos en el diseo. Los objetivos

de la revisin tcnica formal

son:

(a) Descubrir errores en la

funcin, la lgica o la implanta-

cin de cualquier representacin

del software.

(b) Verificar que el software

bajo revisin alcanza sus requisi-tos.

(c) Garantizar que el softwa-

re ha sido representado de

acuerdo con ciertos estndares

predefinidos.

(d) Conseguir un softwaredesarrollado de forma uniforme.

(e) Hacer que los proyectos

sean ms manejables.

Estrategia de prueba

La prueba del software es un

elemento crtico para la garanta

de calidad del software y repre-

senta una revisin final de las es-

pecificaciones, del diseo y lacodificacin. La prueba requiere

que se descarten las ideas pre-

concebidas sobre la correc-

cin del software que se acaba

de desarrollar y se supere cual-

quier conflicto de intereses que

aparezca cuando se detecten

errores.

En un libro clsico sobre la

prueba del software (Myers,

1979) se establecen una serie

de reglas que pueden enten-

derse como objetivos de laprueba:

(a) La prueba es un proceso

de ejecucin de un programa

con la intencin de descubrir un

error.

(b) Un buen caso de prueba

es aquel que tiene una alta pro-

babilidad de mostrar un error

no descubierto hasta entonces.

(c) Una prueba tiene xito si

descubre un error no detectadohasta entonces.

Debido a la importancia de

las pruebas para la calidad y a

su dif icultad, existen mlti-

ples tcnicas de prueba. En

(Press m, 1995) se muestran

algunas de estas tcnicas deprueba.

Procedimiento queasegure un ajuste alos estndares dedesarrollo del software

En la segunda parte de este

artculo se muestran algunos de

los estndares de calidad ms

utilizados hoy en da.

Gestin deconfiguraciones desoftware (control de ladocumentacin delsoftware y de loscambios realizados)

La gestin de configuracio-

nes del software es una activi-

dad protectora que se aplica

a lo largo del proceso de inge-

niera del software. Se tratade un conjunto de actividades

de seguimiento y control que

comienza al principio del pro-

yecto de desarrollo del soft-

ware y finaliza slo una vez

que el software queda fuera

de circulacin. Los elementos

que componen toda la infor-

macin producida se denomi-

nan configuracin del softwa-

re (programas, documentos

que describen los programas y

estructuras de datos). La ela-

boracin de la documentacinresulta muy costosa, por lo

que es necesario intentar re-

ducirla lo ms posible y reali-

zarla cuando los beneficios





7/7

que conlleve superen el coste

de su realizacin.

Una de las principales ame-nazas para la calidad del soft-

ware viene de una fuente apa-

rentemente benigna: los cam-

bios. El proceso de control de

cambios contribuye directa-

mente a la calidad del software.

El control de cambios se aplica

durante el desarrollo del soft-

ware y, posteriormente, duran-

te su mantenimiento. Ya que un

cambio se puede producir en

cualquier momento, las activi-

dades de la gestin de configu-

raciones del software sirvenpara: (1) identificar el cambio;

(2) controlar el cambio; (3) ga-

rantizar que el cambio se imple-

menta adecuadamente; (4) in-

formar del cambio a todos

aqullos a los que afecte.

En (Belin, 1998) se mues-

tran de manera resumida las

ideas principales de la gestin

de la configuracin.

Mecanismos de medida

La medicin es una activi-

dad fundamental para cual-quier disciplina de ingeniera.

Un objetivo importante de la

garanta de calidad es seguir la

pista a la calidad del software

y evaluar el impacto de los

cambios de metodologa y de

procedimiento que intentan

mejorar la calidad del softwa-

re. Para conseguirlo, se deben

recolectar mtricas del soft-

ware, como se ver ms ade-

lante.

Registro y realizacinde informes

Son procedimientos para la

recoleccin y divulgacin de

informacin de la garanta de

calidad del software. Los re-

sultados de las revisiones, au-

ditoras, control de cambios,

prueba y otras actividades de

la garanta de calidad deben

convertirse en una parte del

registro histrico de un pro-

yecto. Adems, deben ser di-vulgados a la plantilla de desa-

rrollo para que tenga conoci-

miento de ellos.

Conclusiones

En esta primera parte del

artculo se han pesentado

los factores que afectan a la

calidad del software y cules

son las tareas que hay que rea-

lizar para garantizarla. En lasegunda parte del artculo se

estudiarn con cierto detalle

dos de estas tareas: los estn-

dares y modelos de referencia y

los mecanismos de medida.

Tambin se presentarn las res-

tricciones que tiene algunas de

estas tcnicas y su uso en la ac-

tualidad. Finalmente, se pre-

sentarn las conclusiones gene-

rales del artculo.a



Belin, M. d. L. (1998). La gestion de configuration: points

de repre. Revue de l'Electricit et de l'Electronique,

6(Juin), 58-61.

Brackett, J.W. (1990). Software Requirements (sei-cm-19-1.2):

Canegie Mellon University - Software Engineering Institute.

Durn Toro, A., Bernrdez Jimnez, B., Corchuelo Gil, R., &

Toro Bonilla, M. (2000). Ingeniera de Requisitos y Tecnolo-

ga de Objetos. Novtica, Ene/Feb, 15-20.

Dutta, S., Lee, M., & Van Wassenhove, L. (1999). Software

Engineering in Europe: A study of best practices. IEEE Soft-ware, May/June, 82-90.

Fitzgerald, B., & O'Kane,T. (1999). A Longitudinal Study of Soft-

ware Process Improvement. IEEE Software(May/June), 37-45.

IEEE. (1990). IEEE Standard Glossary of Software Enginee-

ring Terminology. IEEE/ANSI Standard 610.12-1990 : IEEE.

McCall, J. (1977). Factors in Software Quality : General Electric.

Myers, G. J. (1979). The Art of Software Testing: Wiley-In-

terscience.

Nistal Rosique, G. (1999). Presentacin del monogrfico de

Calidad del Software. Novtica, 137(En-Feb).

Pressman, R. S. (1995). Ingeniera del Software: Un enfoque

prctico (Software Engineering. A Practitioner's Approach.,

Trans.). (Cuarta Edicin ed.): McGraw-Hill/Interamrica deEspaa, S.A.

Bibliografa


factores de calidad mccall

Documents