Vous êtes sur la page 1sur 11

Evaluación de la Calidad de Software en Sistemas de Información en

Internet
Leticia Dávila Nicanor, Pedro Mejı́a Alvarez
CINVESTAV-IPN. Sección de Computación
Av. I.P.N. 2508, Zacatenco. México, DF. 07300
ldavila@computacion.cs.cinvestav.mx, pmejia@cs.cinvestav.mx

Resumen pos de investigación, de los cuales uno de los más


A pesar del gran número de artı́culos de investigación y destacados es el modelo de McCall [1]. Este modelo
normas existentes sobre el tema de validación de calidad establece tres áreas principales que intervienen en la
del producto de software, existen hoy en dia muy pocas In- calidad del software:
dustrias de Software que utilicen procesos de evaluación y
análisis para este efecto. Actualmente, la gran mayorı́a de 1. Calidad en la operación del producto. Re-
estudios están enfocados a las actividades de administra- quiere que el software pueda ser entendido
ción de los proyectos de desarrollo de software. En diversos fácilmente, que opere eficientemente y que los
entornos industriales y académicos, la calidad del softwa- resultados obtenidos sean los requeridos inicial-
re ha sido evaluada (validada) mediante distintos estudios mente por el usuario.
analı́ticos. De dichos entornos, la evaluación de la calidad
del software ha evolucionado hacia modelos formales es- 2. Revisión de la calidad del producto de softwa-
tadı́sticos que se basan en métricas como fundamento para re. Tiene como objetivo realizar revisiones du-
el aseguramiento, control y evaluación de la calidad de un rante el proceso de desarrollo para detectar los
producto o proceso de software. Grandes compañı́as co- errores que afecten a la operación del producto.
mo IBM, Hewlett Packard, Motorola y Siemens, entre otras,
fundamentan su marco de producción de software con éste 3. Calidad en el proceso. Requiere de la definición
enfoque estadı́stico, lo cual las ha convertido en pioneras de de estándares y procedimientos que sirvan como
este campo. base para el desarrollo del software.
La contribución del presente trabajo está dirigida al desa-
rrollo de una metodologı́a para la evaluación y el análisis de Otro modelo que es importante resaltar es el de
los atributos de calidad en los productos de software para Boehm [1]. Este modelo, descrito en la Figura 1, des-
Internet. En este trabajo, empleamos la teorı́a de modela- taca por ser uno de los mejor definidos. El modelo es
ción estadı́stica para el análisis y evaluación de los atributos de naturaleza jerárquica y los criterios de calidad se
de calidad. Nuestro principal objetivo es lograr que esta me- presentan en tres grandes divisiones. La primer divi-
todologı́a sirva de modelo para cualquier organización que sión es hecha acorde a los servicios que el sistema
requiera llevar a cabo la validación de los atributos de cali- ofrece (Portabilidad). La segunda se hace de acuerdo
dad en sus productos de software. a la operación del producto (Usabilidad) y la tercera
Palabras Clave: división se hace de acuerdo a la Mantenibilidad del
Sistema de Información en Internet, Calidad, Confiabilidad, producto de software.
Métricas de Software, Evaluación, Modelos Estadı́sticos, Indepenencia
de dispositivo
Portabilidad
PSP Ser contenedores

Presición

Completitud

1 Introducción Integridad /
Robustez

Confiabilidad Consistencia

Lograr un alto nivel de calidad de un producto o servi- Utilidad general Usabilidad Eficiencia
Compatibilidad

cio es el objetivo de la mayorı́a de las organizaciones Ingeniería social


Eficiencia
del dispositivo

que desarrollan software. La administración de la ca- Accesibilidad


Pruebas
lidad del software utiliza procedimientos y estándares Mantenibilidad
Comunicación

durante el desarrollo del software, además del corres- Claridad

pondiente proceso que verifica que todo el personal Entendibilidad


Estructuración.

Consistencia
siga estos estándares. En un esfuerzo por definir el Legalidad
concepto de calidad, algunos autores argumentan que Modificabilidad Crecimiento
un atributo de calidad puede contribuir a la obtención
de mejoras en el funcionamiento y operación del soft- Figura 1: Modelo de Boehm para Clasificar los Crite-
ware. rios de Calidad
De acuerdo a la terminologı́a de la IEEE [1], la cali- De acuerdo al estudio de Perry [1], descrito en la Fi-
dad de un sistema, componente o proceso de desarro- gura 2, es posible observar que la relación que man-
llo de software, se obtiene en función del cumplimien- tienen los atributos de calidad varı́a. Cuando los atri-
to de los requerimientos iniciales especificados por el butos mantienen una relación inversa, se asume que
cliente o usuario final. algunos atributos transgreden la operación de otros.
Las especificaciones de la calidad de un producto Por otro lado, cuando los atributos mantienen una re-
de software han sido objeto de trabajo de varios gru- lación directa se asume que es posible que estos se
puedan beneficiar entre sı́. Por ejemplo, si observa- • Seguridad. Representa la capacidad de que el
mos el aspecto de Confiabilidad, veremos que la Reu- sistema no afecte su entorno y el de quien lo utili-
sabilidad le afecta; por el contrario la Mantenibilidad za.
le favorece. Esto es debido a que la Confiabilidad se
refiere a la seguridad de la operación sin errores de • Protección. Representa la capacidad del sistema
un sistema, módulo ó función. Mientras que el obje- para protegerse a si mismo de intrusiones acci-
tivo de un código reusable es que un mismo código dentales o programadas.
pueda operar en distintos ambientes de desarrollo; lo
que aumenta la probabilidad de tener errores difı́ciles Sin embargo la Disponibilidad, Seguridad y Protec-
de percibir dentro del código. Por el contrario la Mate- ción se ven afectadas por la Fiabilidad.
nibilidad se enfoca a reducir el número de errores de Para evaluar la Fiabilidad debemos tomar en cuen-
un sistema, módulo ó función. La conclusión del estu- ta que los sistemas de software no son entidades
dio es que los atributos de calidad que debe tener un estáticas. La Fiabilidad de un sistema se complica
producto de software dependen en gran medida del a medida que este crece. Es posible caracterizar el
objetivo del desarrollo del producto de software, de su comportamiento de la Fiabilidad estudiando el com-
proceso de desarrollo y de su contexto de operación. portamiento de las fallas. Para lo cual podemos con-
En nuestro trabajo proponemos una metodologı́a siderar por ejemplo el tiempo de arribo de fallos, el
para la validación de los atributos de calidad en los número de fallos ocurrido en un tiempo determinado,
sistema de información en Internet. Este artı́culo está la media del tiempo de ocurrencia de fallas. En to-
compuesto por las siguientes secciones. La Sección dos estos casos estamos afectados por variables alea-
2 describe los atributos de calidad y la importancia de torias. Podemos realizar modelos subsecuentes del
los sistemas de información en internet. En la Sec- comportamiento de las fallas tratándolas como parte
ción 3 se describe la metodologı́a que proponemos de un proceso estocástico.
para evaluar el sistema de información. Ası́ mismo, Cuando el software falla es necesario localizar y re-
en esta sección se describe el proceso de modelado parar las fallas que causan los errores del sistema.
estocástico y el proceso de evaluación que seguire-
mos en la metodologı́a propuesta. En la Sección 4 se 2 Sistemas de Información en In-
decribe un caso de estudio que nos permitirá evaluar
nuestra metodologı́a. Finalmente en la Sección 5 ex- ternet
pondremos las conclusiones de nuestro trabajo. Debido a la importancia que la calidad de software en
Correciones C
Internet ha despertado en los ultimos años, la Confe-
rencia Internacional de la Ingenierı́a de Software del
Confiabilidad C
año 2002 (ICSE 2002) se centró en los aspectos de
Eficiencia E Calidad para los Sistemas en Internet [4], [5]. En es-
Integridad I ta conferencia se concluyó que los criterios de calidad
Usabilidad U
más importantes son los siguientes:
Mantenibilidad M
• Fiablidad
Pruebas
P

Flexibilidad F • Usabilidad
Portabilidad
P • Seguridad
Reusabilidad R
Interoperabilidad • Disponibilidad
I

Figura 2: Relación entre los atributos de calidad para • Escalabilidad


un producto de software. Las marcas obscuras impli- • Mantenibilidad
can una relación inversa, y las marcas claras expresan
una relación directa Con lo descrito anteriormente, es posible darnos
cuenta que el estudio de los atributos de calidad pa-
1.1 Confiabilidad ra sistemas de software puede ser muy extenso. Por
lo tanto, en este trabajo nos centraremos en los siste-
La confiabilidad de un sistema de computo es una pro- mas de información en Internet, debido a la importan-
piedad que implica el grado de confianza esperado por cia que estos han adquirido en años recientes.
parte del usuario en la operación adecuada del siste- La red Internet fué originalmente diseñada para
ma al utilizarlo. La Confiabilidad se ve afectada por transportar información de forma rápida y eficiente a
cuatro espectos fundamentales [2], [3]: cualquier parte del mundo. Ası́ mismo, la Internet fue
diseñada para presentar información, mediante una
• Disponibilidad. Define la probabilidad de que el apariencia sencilla, con sitios (o portales) sin una com-
sistema este funcionando en un tiempo determi- plejidad significativa, ya que su contenido era primor-
nado. dialmente de texto e hipervı́nculos. Sin embargo, a
medida que fue creciendo la Internet, las aplicaciones
• Fiabilidad. Es la probabilidad de que el sistema se volvieron más complejas y con mayores demandas
funcione correctamente durante un intervalo de de Confiabilidad. Algunos ejemplos de estas aplica-
tiempo. ciones son el comercio electrónico, las aplicaciones
distribuidas, las Intranets, etc. Mucha de la comple- Es importante mencionar que los 3 pasos de esta
jidad asociada al desarrollo de aplicaciones en Inter- metodologı́a se utilizan actualmente en muchas indus-
net, tiene que ver con el proceso de desarrollo elegido trias de software. Sin embargo, hasta donde hemos
y también con la integración de los elementos que las podido investigar, el primer paso no está formalizado
conforman. Cada dı́a, un mayor número de organiza- en la literatura actual, y por otro lado, ha habido poca
ciones manejan su información por medio de sistemas divulgación por parte de las industrias de software de
en Internet, por lo cual, se demanda una mayor cali- los procesos que siguen para conseguir calidad. Por
dad en todos los aspectos, para este tipo de sistemas esta razón, la contribución de este artı́culo consiste en
de software. la formalización de la evaluación de la calidad para los
productos de software.

3 Establecimiento de la Metodo- 3.1 Fases de la Metodologı́a


logı́a Las fases utilizadas en nuestra metodologı́a son las
siguientes:
El objetivo de este trabajo es el desarrollo de una me-
todologı́a para la evaluación del comportamiento del 1. Evaluación del atributo de calidad en el siste-
atributo de calidad Confiabilidad en los sistemas de ma ideal.
información en Internet. La meta en esta fase, es obtener un modelo que
Los objetivos particulares de la metodologı́a son los describa el comportamiento de los atributos de
siguientes: calidad para un sistema ideal. Para el funciona-
miento del sistema ideal se utilizarán técnicas de
1. Evaluación y Predicción de la Calidad. simulación. Con la simulación operando aplica-
remos el proceso de evaluación y el análisis que
En este objetivo se pretende evaluar y predecir
describiremos en la sección 3.3. El modelo obte-
la calidad del producto de software mediante la
nido servirá de guı́a durante el desarrollo del pro-
aplicación de métricas de software y modelos es-
ducto (sistema real) de software.
tadı́sticos. Con el apoyo de las técnicas de mo-
delación estadı́stica [7] realizaremos un análisis Es importante destacar, que los productos de
del comportamiento del sistema y de sus atributos software en Internet tienen caracterı́sticas y ne-
de software. Los resultados de nuestro análisis cesidades diversas, aunque el contexto de ope-
serán evaluados mediante un caso de estudio, en ración sea el mismo (la Internet). Utilizar un mo-
donde evaluaremos el comportamiento del siste- delo ya establecido que sirva de guı́a para todos
ma bajo condiciones ideales y las compararemos los productos resulta poco fiable; debido a que
contra la operación del sistema en un contexto los requerimientos son distintos en cada produc-
real. Una vez hecha esta comparación, seremos to. Por lo tanto, es necesario obtener el modelo
capaces de evaluar que tan lejos está el compor- que mejor se ajuste a las necesidades particula-
tamiento de nuestro sistema del funcionamiento res de cada producto de software. Además, el
ideal. modelo obtenido no será el mismo para todos los
atributos de calidad de software a evaluar, debido
2. Mejora de los Procesos. a que cada atributo evalúa diferentes propiedades
del sistema.
En este objetivo se busca introducir el modelo
PSP (Proceso de Software Personal) [6] al pro- 2. Evaluación del atributo de calidad en el siste-
ducto de software, en busca de mejoras del pro- ma real (inicial).
ceso y producto. La introducción del Proceso de En esta fase nuestra meta es obtener el modelo
Software Personal en nuestra metodologı́a, nos que exprese la situación cualitativa del producto
permitirá mejorar el funcionamiento del producto de software. El sistema real, es un sistema de
de software, y con ello mejorar el comportamiento información en Internet para inscripciones en una
de los atributos de calidad. Universidad. Mediante la evaluación del compor-
tamiento del sistema real y del análisis de los re-
3. Administración de la Calidad. sultados conoceremos la situación actual del atri-
En este objetivo se implementará un proceso de buto de calidad de interés.
administración de calidad y las actividades clave El proceso de evaluación y análisis de los resulta-
del proceso para el aseguramiento, la planeación dos para el sistema ideal y real se describe en la
y el control de la calidad del producto. Sección 3.4.

Los primeros 2 pasos de esta metodologı́a se reali- 3. Implementación del Proceso de Mejora.
zan en forma iterativa hasta que los atributos de cali- El objetivo de esta fase es aplicar PSP (Proceso
dad estén tan cercanos al ideal como se requiera. de Software Personal) al desarrollo del producto
En este artı́culo, nos centraremos en la primera par- de software, con el fı́n de mejorar el desempeño
te de esta metodologı́a, que consiste en la evaluación de los atributos de la calidad en el producto de
y predicción de la calidad del producto de software. software. Las condiciones del ambiente de de-
La implementación del modelo PSP y la administra- sarrollo y el tipo de producto de software influyen
ción de la calidad del producto de software están ac- en la selección del proceso de mejora. Además,
tualmente en fase de desarrollo, por lo cual no serán es importante tomar en cuenta como entradas las
descritos en este artı́culo. necesidades de calidad de la organización.
4. Evaluación del sistema final. Nuestro problema radica en estudiar el comporta-
Para cuantificar las mejoras obtenidas con la im- miento de la Fiabilidad en los sistemas de Información
plementación del proceso de mejora (PSP) eva- en Internet. En la gran mayorı́a de los casos este tipo
luaremos nuevamente el atributos de calidad del de sistemas están conformados por un gran número
producto de software. Esperamos que el modelo de módulos. La tendencia al crecimiento en cuanto al
resultante se acerque al comportamiento del mo- tamaño del sistema se ve influenciada por el volumen
delo ideal. De cualquier forma, dependiendo de de información que normalmente manejan. En la ma-
los requerimientos de calidad esperados se deci- yorı́a de los tipos de modelos, el tamaño del sistema
dirá el número de iteraciones Evaluación-Mejora a analizar viene a ser una restricción. Por otro lado es
necesarias. importante contemplar que la metodologı́a se enfoca a
organizaciones, por lo cual el tipo de modelo seleccio-
5. Análisis de los resultados y conclusiones. nado no debe ser demasiado complicado. De acuerdo
al anterior análisis de técnicas de modelado conclui-
Despues de aplicar el proceso de mejora un mos que la opción que mejor se adapta a nuestro ob-
número determinado de veces, llegaremos a ob- jetivo es la obtención de Modelos Estadı́sticos, la cual
tener la calidad deseada en el producto de soft- describiremos a detalle y la aplicaremos a un caso de
ware. En esta fase, se llevará a cabo un análisis estudio.
de las evaluaciones obtenidas del producto de
software, ası́ como la identificación y la cuantifi-
cación de la mejoras obtenidas durante el proce- 3.3 Empleo de Modelos Estadı́sticos
so. Ası́ mismo, se llevará a cabo una comparación Los modelos estadı́sticos tienen su base en el estudio
de los objetivos planteados contra los objetivos de poblaciones. Una población es un conjunto limi-
alcanzados. Este análisis deberá registrarse en tado de individuos o elementos de la misma especie
bitácoras, ya que servirá para mejorar la calidad sometidos a un estudio estocástico. Estos elementos
de productos de software futuros. tienen propiedades fundamentales en común, que son
la base para clasificar a la población.
En nuestro caso, el objeto de estudio (o la pobla-
3.2 Técnicas de Modelado ción) son los atributos de calidad de software. Las
Existen diversas técnicas de modelado como son las métricas de software permiten evaluar a la población.
Cadenas de Markov, Redes de Petri, Verificación de Nuestro interés consiste en estudiar la tendencia del
modelos (Model Checking), Modelos Estadı́sticos . comportamiento de los atributos de calidad (en par-
ticular la Confiabilidad) del producto de software. Para
• Cadenas de Markov. Es una serie de eventos en lo cual nos proponemos evaluar y analizar el compor-
la cual la probabilidad de que ocurra un evento tamiento de los atributos de calidad asociados a un
depende del evento inmediato anterior. Sin em- producto de software mediante el estudio de su distri-
bargo no se recomiendan para modelar Fiabili- bución estadı́stica. La evaluación del comportamien-
dad, debido a que no distinguen entre los fallos to de estos atributos la realizaremos con métricas de
seguros y los no seguros, por otro lado no toman software, y sus resultados los describiremos median-
en cuenta el proceso de restauracion o reparacion te histogramas. El problema fundamental consiste en
en un sistema [8]. reemplazar el histograma por una curva teórica ó mo-
delo que represente una ley de probabilidad. Esta ley
• Redes de Petri. Son grafos orientados a la mode- de probabilidad será la imágen definitiva de la pobla-
lación mediante nodos llamados lugares que re- ción de las métricas de software estudiadas, y permi-
presentan estados o acciones y transiciones que tirán describir el comportamiento del atributo de cali-
representan eventos, normalmente este modela- dad.
do se representa por conjuntos de cuádruplas. A El procedimiento para obtener el modelo estadı́stico
medida que crece el sistema, el número de nodos consiste de los siguientes pasos.
y de transiciones aumenta y como consecuencia
el número de variables que maneja se va multipli- 1. Escoger el tipo de ley de probabilidad que nos
cando [9]. proponemos asociar a la población. Esta ley
podrı́a tener un origen puramente empı́rico; por
• Verificación de modelos (Model Checking). Es un ejemplo, el histograma de los errores que ocurren
modelo que se basa en la especificación formal durante un lapso de tiempo en la operación de un
de los módulos o programas que son representa- producto de software. Ejemplos de estas leyes
dos por sistemas de transición con estados. Pero podrı́an ser, la distribución de Weibull, la Normal,
cuando el espacio de estados es demasido gran- la de Poisson, o la Gamma.
de, este enfoque resulta inapropiado [10].
2. Evaluar los parámetros contenidos en la ley esco-
• Modelos Estadı́sticos. Es un modelo orientado al gida. Una ley contiene parámetros que dependen
estudio de poblaciones (por ejemplo métricas de de la población estudiada. La modelación nos
software). El cual se puede expresar como una proporciona las expresiones para obtener el va-
relación entre entidades a las que se les repre- lor de estos parámetros para todos los modelos.
senta mediante funciones de distribución. Lo que
lleva a la obtención de una ley de probabilidad 3. Comparar la ley escogida. Una vez escogido el
que representa el comportamiento de los atribu- tipo de ley y valorados los parámetros numéricos,
tos de dicha población [11]. debemos verificar que la ley está de acuerdo con
la población estudiada. El resultado de la com- • El presupuesto asignado al desarrollo del
paración puede ser favorable o desfavorable. Si producto de software. El presupuesto tiene
es favorable, expresarı́a que la ley escogida re- un impacto directo en la selección del per-
presenta fielmente a la población estudiada. De sonal, de los componentes utilizados y del
lo contrario, serı́a necesario buscar otra ley que tiempo de desarrollo del producto de softwa-
represente mejor el comportamiento de la pobla- re.
ción.
• Las condiciones de calidad impuestas por la
organización.

3.4 Proceso de Evaluación y Modelación Tiempo de evaluación. En la selección de las


métricas también influyen las unidades de tiem-
El proceso para realizar la evaluación del producto de po necesarias para realizar las mediciones. Estas
software, el análisis de los resultados y la modelación pueden unidades pueden ser unidades de tiempo
se compone de los siguiente pasos. de CPU, dı́as, semanas, meses o incluso años.

1. Determinación de las condiciones iniciales. 3. Proceso de Medición.


Cada fase tiene su enfoque para valorar las condi- La medición del software se refiere a derivar un
ciones del ambiente de operación del producto de valor numérico para algún atributo de un produc-
software. Tomar en cuenta éstas condiciones es to de software. El proceso de medición es una
básico para el proceso de evaluación. Por ejem- actividad clave, ya que de éste depende que los
plo, algunas de estas condiciones podrı́an ser: (a) resultados puedan ser fiables y fáciles de evaluar.
las entradas del sistema, (b) sus restricciones, y
Los pasos a seguir en este proceso son los si-
(c) los servicios que proporciona el sistema.
guientes.
2. Selección del atributo de calidad y de sus
métricas de software. a. Seleccionar los componentes a evaluar.

Es fundamental definir el atributo de calidad de b. Medir las caracterı́sticas de los componen-


software que pretendemos estudiar. En la selec- tes con las métricas de software.
ción del atributo influyen las necesidades priorita- c. Identificar las mediciones anómalas.
rias de cada organización en sus productos de
d. Analizar los componentes anómalos.
software. Una véz seleccionado el atributo de
calidad es necesario verificar su correspondiente
métrica. En la selección de las métricas influyen 4. Evaluación de los resultados y selección del
los siguientes factores: modelo.

Tipos de métricas. Las métricas que se van a La evaluación del proceso de medición la reali-
emplear dependen del atributo de calidad a eva- zamos mediante el estudio de su distribució es-
luar y de las condiciones de desarrollo y opera- tadı́stica. Los resultados de esta evaluación per-
ción del sistema. Los atributos de software más miten analizar el conjunto de datos obtenidos me-
comunes son los mostrados en las Figuras 1 y diante gráficas conocidas como histogramas (los
2. Para cada atributo es posible que existan va- cuales pueden obtenerse mediante herramientas
rios tipos de métricas de software que se pueden como Arena). Los histogramas permiten repre-
aplicar. En algunos casos las métricas de soft- sentar los valores de la métrica contra su frecuen-
ware existentes no son aplicables al ambiente de cia. Estos histogramas nos darán una aproxima-
operación del proyecto, o estas son difı́ciles de ción al tipo de modelo que mejor se ajusta al com-
obtener. En estos casos es posible implementar portamiento de los resultados obtenidos. Nos in-
nuevas métricas que están de acuerdo a las nor- teresa reemplazar el histograma por una ley de
mas de calidad de la organización. Compañı́as probabilidad que mejor represente este compor-
como Motorola, IBM y Hewlett Packard han desa- tamiento. Esta ley de probabilidad será el reflejo
rrollado métricas que se adecuan a su marco de del comportamiento de la población de métricas
producción [12]. estudiadas. La ley escogida nos podrá indicar si
nuestra evaluación fue correctamente realizada.
Condiciones de desarrollo. Las condiciones de
desarrollo del sistema permiten describir: 5. Estimación de los parámetros del modelo.
De acuerdo a la sección 3.3, esta actividad es
• Proceso de desarrollo de software utilizado.
parte fundamental en la obtención del modelo.
Existen distintos procesos de desarrollo co-
Para la obtención del modelo se usan diversas
mo son: (a) Proceso de desarrollo en cas-
técnicas de métodos numéricos, como el método
cada, (b) Proceso evolutivo, (c) Proceso en
de los MLEs (maximun - likelihood estimators), el
espiral, (d) Prototipado ó (e) Reutilización de
método de los mı́nimos cuadrados, regresión po-
componentes.
linomial, entre otras. En ocasiones, es necesario
• El personal involucrado en el desarrollo. De- aplicar varios métodos para llegar a resultados
pendiendo del dominio de la aplicación es confiables, y dependiendo del parámetro a esti-
necesario verificar que el personal sea es- mar algunos métodos son mas adecuados que
pecialista en el área de dominio. otros.
6. Sustitución de los parámetros obtenidos y principales: (a). Investigadores/Profesores, (b) Alum-
graficación del modelo resultante. nos, (c) Público en general. El acceso al sistema es
Una vez obtenidos los parámetros resultantes, con usuario y password. Cada usuario del sistema
éstos son graficados a fı́n de observar su tenden- tendrá acceso a distintos servicios que proporciona el
cia. La gráfica obtenida representa el comporta- sistema. En general se pretende que el sistema pro-
miento del atributo de calidad. vea los servicios de altas de cursos calificaciones y
alumnos, con sus respectivas bajas y modificaciones.
7. Validación del modelo escogido.
Con los parámetros obtenidos debemos verificar 4.2 Fase 1: Determinación del comporta-
que el modelo, tal y como fué construido está de miento ideal de la Fiabilidad
acuerdo con la población de métricas estudiada. En esta fase, se evaluará y modelará el comporta-
Por lo tanto en este proceso, se realiza una com- miento del sistema bajo condiciones ideales, aplican-
paración de los valores que se obtienen con el do el proceso definido en la Sección 3.3.
histograma contra los resultados que se obtienen
con el modelo. 1. Determinación de las condiciones iniciales
para el caso ideal.
8. Realización de las predicciones del atributo de
calidad. Las condiciones para la simulación son las si-
guientes:
En este proceso, las predicciones del atributo de
calidad se realizan mediante la observación del El tiempo entre arribos de los usuarios al sistema
modelo (o ley de probabilidad) obtenido. Con es- se presenta siguiendo una distribución exponen-
te modelo, además de representar el comporta- cial con una media µ = 5 unidades de tiempo.
miento de los atributos de calidad, es posible tam- El tiempo que permanece cada usuario utilizando
bién predecir el comportamiento a futuro de estos el sistema posee una distribución normal con una
atributos. media µ = 5 unidades de tiempo y una varian-
za σ = 3. La modelación del arribo de usuarios
se hace mediante colas, para lo cual se utilizó un
servidor de colas del tipo M/M/1 en el pool del
4 Caso de Estudio servidor web 1 con una probabilidad de (n + 1)−1 ,
En esta sección describiremos mediante un caso de donde n representa el tamaño actual de la cola
estudio las dos primeras fases de la metodologı́a. (número de usuarios en el sistema). La condición
En nuestro caso de estudio, evaluaremos un siste- de salida del sistema para cualquier usuario se
ma de inscripciones vı́a Internet (SIV) para una Uni- presenta, (a) cuando se genera un error del usua-
versidad. La arquitectura del sistema consiste en una rio durante la operación del sistema, y (b) cuando
plataforma Linux (Redhat v.8), un manejador de ba- el usuario solicita su salida del sistema.
ses de datos (MySQL [13]), un servidor Web (Apache Por razones de fiabilidad, en cuanto a la capaci-
[14]). El lenguaje utilizado para las interfaces de usua- dad del servidor Web y la del manejador de la Ba-
rio fue (PHP [15]). El número de lı́neas de código utili- se de Datos, el sistema puede trabajar adecuada-
zadas en la implementación del sistema fue de 1200. mente hasta con k usuarios (donde k = 100). De-
El tiempo empleado para el desarrollo del sistema y pendiendo de su vista, los usuarios pueden reali-
de su documentación ha sido de 6 meses aproxima- zar solo x tipos de transacciones, con t unidades
damente. El diagrama a bloques de sistema se puede de tiempo para realizar cada transacción. Don-
observar el la Figura 3. de x depende de la vista, y t sigue una distribu-
ción normal con una media µ = 5 y una varian-
Acceso al sistema Alta de claves de
acceso al sistema
za σ = 3. El problema consiste en determinar el
Vista del público en general
número de errores que se generan en el sistema
Establecimiento
Vista de los alumnos en un lapso de tiempo determinado. El acceso de
Vista de los investigadores
del perfil
los usuarios y las vistas de información corres-
Información Información de Información
personal
pondiente a cada perfil.
de cursos cursos de alumnos de los alumnos
El lenguaje de programación empleado para la si-
Consultas mulación fué Java.
En la simulación se emplea un modelo
Altas productor − consumidor, en donde la infor-
Control del
mación se maneja mediante una cola de recursos
Bajas periodo
de cambios compartidos. La sincronización del productor-
consumidor se realizó mediante la sincronización
Cambios
de hilos. El productor tienen la función de generar
los datos de salida para el consumidor, de acuer-
Figura 3: Módulos que conforman el Sistema de Infor- do al funcionamiento del modelo lógico descrito
mación via Internet (SIV) en la Figura 4. La función del consumidor es
1 De acuerdo a la Notación de Kendal [7], en la notación A/B/s,

4.1 Planteamiento del Problema A se refiere a la distribución de los tiempos entre arribos, B es la
distribución de los tiempos de servicio y s representa el número
Se trata de un Sistema de Inscripciones vı́a Internet de servidores. Las distribuciones más comunes son M (Markov, o
para una Universidad, en donde existen tres vistas exponencial), G (general), y D (determinista, o constante).
2. Rutina de Incialización 1. Proceso_SIV
Establece el número de sesiones 3. arrive()
para cualquier tipo de usuario
Llama a la rutina de inicialización. Calcula el tiempo del siguiente arribo
Inicializa las estructuras, variables del
sistema y los contadores estadisticos Establece el hilo de ejecución

Calcula el tiempo de arribo y el perfil Hay peticiones en Si


del primer usuario el pool?
5. departure() No
Calcula la probabilidad
Disminuye el tiempo de todos los usuarios ¿Existe algún arribo? de que se quede
Verifica quién finalizó su tiempo y tiene No Si Asigna la
que salir de la sección estructura
del usuario
No Si acorde a Se queda en la
Acabó el tiempo Llama a la
del usuario? función arrive() su perfil cola del pool? Si
No
No Es la ultima Si Aumenta el Aumenta
seccion?
número de el tamaño
Sale abandonos de la cola
Envia los datos a la cola
del de recursos compartidos
Hay espacio en la sistema
sig. sección? Si
No
Es la primera
sección? Si
No El tiempo de simulación llegó No El servidor tiene
a su fin? capacidad para
Disminuye en 1 Si
Si No otro usuario?
la cola del pool
Fin

Aumenta la cola Llama a la función


Regresa a la función 4. AddDeparture() en el pool del AddDeparture()
AddDepature() servidor WEB
Llama a la funcion departure()

No Si
Se genera algún
error?
Aumenta en 1 la
Densidad de defectos

Sale del sistema

Figura 4: Diagrama a bloques del funcionamiento del Productor

actualizar y graficar el comportamiento de la


simulación cada unidad de tiempo, de acuerdo a
los datos que el productor le envı́a a través de la
cola de recursos compartidos. La interfaz gráfica
que se muestra en la Figura 5 se desarrolló
con el fin de visualizar el comportamiento del
productor-comsumidor.

El diagrama a bloques de la operación del pro-


ductor se muestra en la Figura 4. En este diagra-
ma se pueden apreciar 5 módulos. En el módulo
principal, Proceso del SIV, se ejecuta el ciclo de
ejecuciones de la simulación. El segundo módulo
Rutina de Inicialización tiene la función de iniciali- Figura 5: Interface gráfica de la simulación del Siste-
zar las estructuras, los contadores estadı́sticos y ma de Información via Internet
de programar el primer arribo. El tercer módulo,
arrive(), calcula el tiempo de arribo de los usua- 2. Selección del atributo de calidad y de sus
rios, verifica si los usuarios se quedan en la cola métricas de software.
del pool del servidor Web y verifica si el sistema El atributo que nos interesa medir es la Fiabili-
tiene capacidad para más usuarios. En el caso dad. Como se menciona anteriormente, la Fiabili-
de que el sistema tenga suficiente capacidad, se dad nos permite evaluar que tan libre de fallos se
le permite el acceso al usuario y se realiza una encuentra un sistema.
llamada a la función Addeparture(). En el cuarto
módulo, AddDeparture(), se realiza un llamada al Tipos de métricas.
la función departure() y se verifica la generación En nuestro caso nos interesa medir el atributo de
de errores durante la operación simulada. En el Fiabilidad en la operación del producto de softwa-
caso de que hallan existido errores, se aumenta la re. Las métricas que son posibles utilizar para la
densidad de defectos y se le programa al usuario fiabilidad son[12]:
su salida del sistema. El quinto módulo, depar-
ture(), se encarga de programar los tiempos de • densidad de defectos. La densidad de de-
salida para cada usuario para la sección o parte fectos es una métrica de calidad que se de-
del sistema que está utilizando. fine como el número de errores que ocurren
durante un lapso de tiempo determinado. D. Defec Frec x Den. Prob. Dist. Acum.
0 27 0.00 0.0402 0.0402
• media de ocurrencia de fallos. Se refiere 1 47 1.00 0.122 0.163
al promedio del tiempo que tarda en produ- 2 84 2.00 0.179 0.341
cirse un fallo durante la operación de un pro- 3 107 3.00 0.194 0.535
4 86 4.00 0.172 0.707
ducto de software. 5 73 5.00 0.128 0.835
6 40 6.00 0.0824 0.918
En nuestro caso utilizaremos la métrica de densi- 7 20 7.00 0.0439 0.963
dad de defectos. 8 7 8.00 0.0222 0.986
9 6 9.00 0.00938 0.995
Condiciones de desarrollo. Para el caso ideal, 10 3 10.00 0.00347 0.998
como se comenta anteriormente, se desarrolló un
simulador del sistema de Inscripciones por Inter- Tabla 1: Resumen de los resultados obtenidos durante
net en lenguaje Java. Las condiciones de opera- las evaluaciones del caso ideal
ción del simulador se describen en la primera par-
te de esta fase (determinación de las condiciones
iniciales para el caso ideal). 120

Tiempo de evaluación. 100


El tiempo para cada evaluación es el tiempo que
80
tarda cada simulación. Cada evaluacion se lle-

Frecuencia
vo a cabo en 100 unidades de tiempo (lo cual se 60
llevó a cabo en aproximadamente 30 segundos
de tiempo de ejecución). Se llevaron a cabo 500 40
evaluaciones.
20
3. Proceso de medición.
0
a. Selección de los componentes a evaluar. 0 2 4 6 8 10
Densidad de Defectos
La simulación se diseñó para medir todos los
componentes que forman al sistema.
Figura 6: Histograma para 500 simulaciones.
b. Medir las caracterı́sticas de los compo-
nentes con las métricas de software.
En este punto como la métrica fué la den- es un metamodelo [7], en donde α y β son sus
sidad de defectos, la simulación se preparó parámetros.
para que en un marco de tiempo de 100 uni-
dades se contabilizará en número de defec- 5. Estimación de los parámetros del modelo.
tos que aparecieron en la simulación del sis- Los parámetros del modelo se obtienen siguiendo
tema. el procedimiento descrito en la sección 3.2), de la
c. Identificar las mediciones anómalas. Por siguiente forma.
el hecho de tratarse de una simulación que Escoger el tipo de ley de probabilidad que nos
trabaja con condiciones ideales las medicio- proponemos asociar al histograma.
nes anómalas fueron pocas. Se desecharon
α
sólo 5 de 500 ejecuciones de la simulacion. f (x) = αβ −α xα−1 e−(x/β) (1)
d. Identificar los componentes anómalos.
Para el caso ideal no se presentaron com- Evaluar los parámetros contenidos en la ley
ponentes anómalos. Esto fue debido a que escogida.
el número de mediciones anómalas (que fue Del análisis de la Ecuación 1 se obtuvo en [7]
de 0.99% del 100% del total de las medicio- mediante estimadores de máxima verosimilitud
nes), y no se centró en algún componente (maximum-likelihood estimators MLEs), las si-
en particular. guientes ecuaciones que permiten calcular los va-
lores de α y β.
4. Evaluación de los resultados y selección del
Pn α
Pn
modelo. i=1 X lnXi 1 i=1 lnXi
P n α
− = (2)
El resumen de los resultados para nuestro proce- i=1 X α n
so de evaluación y selección del modelo se mues-
µ Pn ¶1/α
tra en la Tabla 1. Los elementos que integran el i=1 Xiα
resumen son los siguientes: Densidad de defec- β= (3)
n
tos (D.Defec), frecuencia (Frec), valor asignado
en el eje x (x),la densidad de la probabilidad (Den. La Ecuación 2 se resuelve mediante el método
Prob) y los valores de la distribución acumulativa de Newton-Rapson, mientras que la Ecuación 3
(Dist. Acum). El histograma que corresponde a se obtiene de manera directa conociendo el valor
estos datos se muestra en la Figura 6. de α. Los valores obtenidos de los parámetros a
Mediante el histograma apreciamos que la ten- partir de las Ecuaciones 2 y 3 son:
dencia de los resultados se aproxima a una distri-
bución (o curva) de Weibull. La curva de Weibull α = 2.11 y β = 4.54.
6. Sustitución de los parámetros obtenidos gra- • Dependiendo de su vista, los usuarios sólo
ficación del modelo ideal fi . pueden realizar un número limitado de tran-
De acuerdo a los valores de α y β antes descritos sacciones.
la función de probabilidad se calcula de la siguien-
te forma. Los resultados obtenidos en cada evaluación se
½ 2.11
almacenaron en bitácoras, y se promediaron con
fi (x) = 5.127x1.11 e−(x/4.54) Si x ≥ 0 el fı́n de graficar los histogramas.
0 En otro caso
2. Selección de los atributos a medir y de sus
La gráfica del Comportamiento de la Fiabilidad de métricas.
acuerdo al modelo ideal fi se presenta en la Fi-
gura 8. Tipos de métricas. Al igual que en caso ideal,
el atributo a evaluar es la Fiabilidad y la métrica
7. Validación del modelo obtenido. para dicho atributo será la densidad de defectos.
De acuerdo a la modelación estadı́stica, la curva Condiciones de desarrollo. En el Sistema de
de Weibull permite representar el tiempo de ocu- Inscripciones por Internet seguimos el modelo de
rrencia de fallos de alguna pieza de un sistema ó desarrollo en cascada. En el desarrollo de este
equipo. Por lo cual, el hecho de que el modelo sistema intervinieron dos personas especialistas
obtenido siga una curva de Weibull nos permite en el desarrollo de sistemas en Internet y el tiem-
validar nuestro proceso. En otras palabras, pode- po de desarrollo fue de 6 meses.
mos decir que la métrica Densidad de Defectos es
Tiempo de evaluación.
la adecuada para representar el comportamiento
de la Fiabilidad del producto de software . El tiempo para la evaluación de cada experimento
fue de 100 unidades de tiempo (lo cual se llevo a
8. Realización de las predicciones de la fiabili- cabo en un lapso de 100 minutos). El número de
dad. experimentos para el caso ideal fue de 500 mien-
De acuerdo a la información proporcionada por tras que para el caso real fue de 70. Esto se debió
el Histograma de la Figura 6, es posible obser- a que los 70 experimentos fueron llevados a cabo
var que la tendencia de la curva describe que la en 3 semanas. Para lograr realizar 500 evalua-
densidad de defectos presenta valores bajos con ciones hubieran sido necesarios varios meses de
un alta frecuencia. Esta conclusión se obtiene del ejecución del proceso de evaluación.
hecho de que en la mayorı́a de las evaluaciones
se obtuvo un bajo número de errores. 3. Proceso de medición.

a. Selección de los componentes a medir.


4.3 Fase 2:Evaluación de la fiabilidad en Durante la operación del sistema real se mi-
el sistema real siguiendo Proceso de dieron todos los componentes que forman al
evaluación y modelación sistema.
1. Determinación de las condiciones iniciales b. Medir las caracterı́sticas de los compo-
para el caso real. nentes con las métricas de software.
Las condiciones del proceso fueron las siguien- En este punto la métrica utilizada fué la den-
tes. Las evaluaciones fueron hechas por un sólo sidad de defectos. Durante cada experimen-
usuario, el cual tomo el rol de tres tipos de vistas: to se contabilizó el número de defectos ocu-
alumnos, investigadores y público en general. La rridos.
forma de realizar las transacciones sobre el Sis- c. Identificar las mediciones anómalas. Du-
tema de Información en Internet fué de manera rante la ejecución del sistema no ocurrieron
aleatoria para cada rol, mediante una matriz de mediciones anómalas.
pruebas. La matriz de pruebas contenı́a los dis-
tintos servicios y los datos requeridos a accesar d. Identificar los componentes anómalos.
del sistema. Esta matriz estuvo compuesta de op- Los errores que encontramos con mayor fre-
ciones válidas y opciones no-válidas. Los datos cuencia en los componentes seleccionados
de prueba fueron tomados de manera aleatoria durante la operación del sistema son los si-
de la matriz de pruebas, para cada evaluación. guientes:
Las condiciones de operación en el sistema fue- Periodo de Inscripciones:
ron las siguientes: • No se actualiza automáticamente la fe-
cha.
• El tiempo entre arribos (de cada usuario) fué
de 100 minutos. Alta de CURSOS:
• El servidor Web operó con un solo procesa- • No reconoce automáticamente la sec-
dor de 500 Mhz. ción a la que pertenece la persona que
da de alta el curso.
• La capacidad del servidor Web y la del ma-
nejador de la Base de Datos con la cual pue- • No valida totalmente la información an-
den operar adecuadamente el sistema (de tes del proceso de inserción en la Base
acuerdo a los estandares del proveedor red- de Datos.
hat) es de hasta 100 usuarios. Alta de cursos por alumno:
D. Defec Frec x Den. Prob. Dist. Acum. α = 1.32 y β = 4.1
0 5 1.00 0.234 0.234
1 20 2.00 0.179 0.414
2 15 3.00 0.137 0.551 Al igual que en caso ideal, los valores de α y β se
3 8 4.00 0.105 0.657 resuelven de acuerdo a las Ecuaciones 2 y 3.
4 9 5.00 0.0805 0.737
5 1 6.00 0.0616 0.799 6. Sustitución de los parámetros obtenidos fr y
6 1 7.00 0.0472 0.846
7 2 8.00 0.0361 0.882 graficación del modelo real.
8 1 9.00 0.0277 0.910 Sustituyendo los valores de α y β en la función
9 1 10.00 0.0212 0.931
10 2 11.00 0.0162 0.947 del modelo real fr nos da la siguiente expresión.
11 5 12.00 0.0124 0.959 ½ 1.32

fr (x) = 3.67x0.32 e−(x/4.1) Si x ≥ 0


Tabla 2: Resumen de los resultados obtenidos durante 0 En otro caso
las evaluaciones del caso real
La gráfica del comportamiento de la Fiabilidad de
acuerdo al modelo real fr se presenta en la Figura
• Permite registrar mas de 4 cursos por
alumno. 8.
Consulta de cursos por alumno: 7. Comparación del modelo obtenido.
• No se presenta la lista completa de Es posible observar que el modelo obtenido pa-
los alumnos que asesora un investiga- ra el caso real sigue una distribución de Weibull.
dor/profesor. El modelo obtenido sigue en contexto con el con-
Alta de alumnos: cepto de Densidad de Defectos, por lo que no se
opone a representar el comportamiento de la Fia-
• No valida totalmente la información an-
bilidad real.
tes del proceso de inserción en la Base
de Datos. 8. Realización de las predicciones de la fiabili-
4. Evaluación de los resultados y selección del dad.
modelo. En la Figura 8 se observa la comparación de los
El resumen de los datos obtenidos durante las modelos resultantes (ideal y real) de las evalua-
70 evaluaciones se presenta en la Tabla 2. Al ciones del caso de estudio. Los parámetros α y β
igual que en el caso ideal en la tabla se regis- representan el grado de aproximación que existe
tran los siguientes valores: Densidad de defectos entre los modelos ideal y real. Para obtener un
(D.Defec), frecuencia de ocurrencia (Frec), la re- producto de software con un buen nivel de fiabili-
presentación en x (x), la densidad de probabilidad dad se debe cumplir lo siguiente.
(Den. Prob.) y la distribución acumulativa (Dist. αr → αi y βr → βi
Acum.). El histograma resultante se presenta en
la Figura 7. Es posible observar en la Figura 8 que el com-
portamiento obtenido del modelo real está aleja-
do del comportamiento del modelo ideal. Esto se
20 puede derivar de la observación de que:

αr 6= αi y βr 6= βi ⇒ fr (x) 6= fi (x).
15
Frecuencia

Por lo tanto, concluimos que son necesarias me-


10 joras en el producto de software, para lo cual será
necesaria la ejecución de la segunda parte de la
metodologı́a, que consiste en el proceso de me-
5
jora PSP.

0
0 2 4 6 8 10 12 Modelo ideal fi(x)
14 Modelo real fr(x)
Densidad de Defectos
12

Figura 7: Histograma para 70 mediciones de errores 10

Mediante el histograma apreciamos que la ten- 8


f(x)

dencia que presentan los datos describe una cur-


va de Weibull. 6

4
5. Estimación de los parámetros del modelo.
2
La función de densidad utilizada para modelar el
caso real es la siguiente. 0
0 2 4 6 8 10 12 14
α
f (x) = αβ −α xα−1 e−(x/β) (4) x

Figura 8: Gráfica del modelo ideal y real para el caso


en donde, los parámetros α y β obtenidos son los de estudio
siguientes.
5 Conclusiones [16] J. Raj. The Art of Computer Systems Performance Ana-
lisys. ISBN 0-471-50336-3. John Wiley and Sons, 1991.
En este trabajo se formuló una metodologı́a para la
validación de sistemas de información en internet. EL
atributo de calidad que se analizó fue la fiabilidad. Se
pretende que esta metodologı́a pueda ser aplicada a
cualquier sistemas de software, y no sólo a los siste-
mas de software en Internet. Es claro que un buen
análisis de calidad es una de las bases más impor-
tantes para la toma desiciones dentro de una orga-
nización que desarrolla software de calidad. Por tal
razón, la evaluación de un producto de software per-
mitirá mejorar el control de la calidad de un producto
de software.
En nuestro trabajo hemos aplicado la modelación
estadı́stica para predecir del comportamiento de los
atributos de calidad de un sistema de software. Me-
diante la evaluación de un caso de estudio, hemos
concluido que la metodologı́a desarrollada es una he-
rramienta eficiente dentro del proceso de desarrollo de
software. Esta herramienta permite controlar la cali-
dad del proceso y del producto de software resultante.
El uso de esta metodologı́a permitirá también lograr
una reducción de costos en el sistema de software y
también de su proceso de su desarrollo.
La metodologı́a propuesta sólo fue ejecutada en su
primer fase de evaluación y predicción de la calidad
del producto de software. Como trabajo futuro nos
proponemos ejecutar completa nuestra metodologı́a
incluyendo el proceso de mejora PSP y su evaluación
iterativa, con el fı́n de mejorar los objetivos de calidad.
Adicionalmente, nos proponemos estudiar otros crite-
rios de calidad como son la usabilidad y la seguridad
utilizando nuestra metodologı́a.

Referencias
[1] A.C. Gillies. Software Quality, Theory and Management.
Thomson Computer Press. 1999.
[2] H. Van Vliet. Software Engineering, Principles and Practice
, Second Edition. John Wiley and Sons, 2001.
[3] I. Somerville. Software Engineering, Sixth Edition. Pearson
Education Limited, Harlow England, 2001.
[4] J. Offutt. Quality Attributes of Web Software Applications.
IEEE Software, 0740-7459/02. March/April 2002.
[5] Becker and F.E. Mottay. A Global Perspective on Web Site
Usability. IEEE Software, 0740-7459/00, January/February
2001.
[6] D. J. Paulish, Siemens Corporation Research and Anita D.
Carleton, Software Engineering Institute. Case Studies of
Software Process-Improvement Measurement. Computer
IEEE 0018-9162/94, pp.50 1994.
[7] A. M. Law, W. David Kelton. Simulation Modeling and
Analysis. Third Edition McGraw - Hill , 2000.
[8] B. Tombuyses, 1999. Reduction of the Markovian system
by the influence graph method - error bound and reliability
computation. Reliability Engineering and System Safety,
vol. 63, No. 1, pp 1-11. 1999.
[9] S. Donatelli, 1994. Suporposed Generalized Stochastic
Petri Nets:Definition and Efficient Solution. Aplication and
Theory of Petri Nets , pp. 258-277, 1994.
[10] E. Clarke, O. Grumberg, and D. Long, Software Enginee-
ring Institute. Model checking and abstraction. ACM Tran-
sactions on Programing Languajes and Systems, vol. 16,
No. 5, pp. 1512-1542, January 1994.
[11] Alberto Moreno Bonett, Francisco Javier Jauffred M.
1997 Elementos de probabilidad y estadı́stica. ISBN:
9701502574. McGraw - Hill , 1997.
[12] S. H. Kan. Metrics and Models in Software Quality Engi-
neering, Second Edition. Addison - Wesley, 2003.
[13] http:// www.mysql.com
[14] http:// www.apache.org
[15] http:// www.php.com