´ de la Calidad de Software en Sistemas de Informacion ´ en Evaluacion Internet ´ Leticia Davila Nicanor, Pedro Mej´ıa Alvarez ´ de Computacion ´ CINVESTAV-IPN. Seccion ´ Av. I.P.N. 2508, Zacatenco. Mexico, DF. 07300
[email protected],
[email protected]
Resumen ´ y A pesar del gran numero de art´ıculos de investigacion ´ ´ de calidad normas existentes sobre el tema de validacion del producto de software, existen hoy en dia muy pocas In´ y dustrias de Software que utilicen procesos de evaluacion ´ analisis para este efecto. Actualmente, la gran mayor´ıa de ´ enfocados a las actividades de administraestudios estan ´ de los proyectos de desarrollo de software. En diversos cion ´ entornos industriales y academicos, la calidad del software ha sido evaluada (validada) mediante distintos estudios ´ de la calidad anal´ıticos. De dichos entornos, la evaluacion del software ha evolucionado hacia modelos formales es´ tad´ısticos que se basan en metricas como fundamento para ´ de la calidad de un el aseguramiento, control y evaluacion ˜ ıas coproducto o proceso de software. Grandes compan´ mo IBM, Hewlett Packard, Motorola y Siemens, entre otras, ´ de software con este ´ fundamentan su marco de produccion enfoque estad´ıstico, lo cual las ha convertido en pioneras de este campo. ´ del presente trabajo esta´ dirigida al desaLa contribucion ´ y el analisis ´ rrollo de una metodolog´ıa para la evaluacion de los atributos de calidad en los productos de software para Internet. En este trabajo, empleamos la teor´ıa de modela´ estad´ıstica para el analisis ´ ´ de los atributos cion y evaluacion de calidad. Nuestro principal objetivo es lograr que esta me´ que todolog´ıa sirva de modelo para cualquier organizacion ´ de los atributos de calirequiera llevar a cabo la validacion dad en sus productos de software.
Palabras Clave: ´ en Internet, Calidad, Confiabilidad, Sistema de Informacion ´ ´ Metricas de Software, Evaluacion, Modelos Estad´ısticos, PSP
´ de los cuales uno de los mas ´ pos de investigacion, destacados es el modelo de McCall [1]. Este modelo ´ establece tres areas principales que intervienen en la calidad del software: ´ del producto. Re1. Calidad en la operacion quiere que el software pueda ser entendido ´ facilmente, que opere eficientemente y que los resultados obtenidos sean los requeridos inicialmente por el usuario. ´ de la calidad del producto de softwa2. Revision re. Tiene como objetivo realizar revisiones durante el proceso de desarrollo para detectar los ´ del producto. errores que afecten a la operacion ´ 3. Calidad en el proceso. Requiere de la definicion ´ de estandares y procedimientos que sirvan como base para el desarrollo del software. Otro modelo que es importante resaltar es el de Boehm [1]. Este modelo, descrito en la Figura 1, destaca por ser uno de los mejor definidos. El modelo es ´ de naturaleza jerarquica y los criterios de calidad se presentan en tres grandes divisiones. La primer divi´ es hecha acorde a los servicios que el sistema sion ofrece (Portabilidad). La segunda se hace de acuerdo ´ del producto (Usabilidad) y la tercera a la operacion ´ se hace de acuerdo a la Mantenibilidad del division producto de software. Indepenencia de dispositivo Portabilidad
Ser contenedores Presición
Completitud
1
´ Introduccion
Integridad / Robustez Confiabilidad
Lograr un alto nivel de calidad de un producto o servicio es el objetivo de la mayor´ıa de las organizaciones ´ de la caque desarrollan software. La administracion ´ lidad del software utiliza procedimientos y estandares ´ del corresdurante el desarrollo del software, ademas pondiente proceso que verifica que todo el personal ´ siga estos estandares. En un esfuerzo por definir el concepto de calidad, algunos autores argumentan que ´ un atributo de calidad puede contribuir a la obtencion ´ del softde mejoras en el funcionamiento y operacion ware. De acuerdo a la terminolog´ıa de la IEEE [1], la calidad de un sistema, componente o proceso de desarro´ del cumplimienllo de software, se obtiene en funcion to de los requerimientos iniciales especificados por el cliente o usuario final. Las especificaciones de la calidad de un producto de software han sido objeto de trabajo de varios gru-
Consistencia Compatibilidad
Utilidad general
Usabilidad
Eficiencia Eficiencia del dispositivo Ingeniería social Accesibilidad Pruebas
Comunicación
Mantenibilidad Claridad
Entendibilidad
Estructuración. Consistencia Legalidad
Modificabilidad
Crecimiento
Figura 1: Modelo de Boehm para Clasificar los Criterios de Calidad De acuerdo al estudio de Perry [1], descrito en la Fi´ que mangura 2, es posible observar que la relacion tienen los atributos de calidad var´ıa. Cuando los atri´ inversa, se asume que butos mantienen una relacion ´ de otros. algunos atributos transgreden la operacion Por otro lado, cuando los atributos mantienen una re´ directa se asume que es posible que estos se lacion
puedan beneficiar entre s´ı. Por ejemplo, si observamos el aspecto de Confiabilidad, veremos que la Reusabilidad le afecta; por el contrario la Mantenibilidad le favorece. Esto es debido a que la Confiabilidad se ´ sin errores de refiere a la seguridad de la operacion ´ ´ un sistema, modulo o´ funcion. Mientras que el obje´ ´ tivo de un codigo reusable es que un mismo codigo pueda operar en distintos ambientes de desarrollo; lo que aumenta la probabilidad de tener errores dif´ıciles ´ de percibir dentro del codigo. Por el contrario la Matenibilidad se enfoca a reducir el numero de errores de ´ ´ ´ La conclusion ´ del estuun sistema, modulo o´ funcion. dio es que los atributos de calidad que debe tener un producto de software dependen en gran medida del objetivo del desarrollo del producto de software, de su ´ proceso de desarrollo y de su contexto de operacion. En nuestro trabajo proponemos una metodolog´ıa ´ de los atributos de calidad en los para la validacion ´ en Internet. Este art´ıculo esta´ sistema de informacion ´ compuesto por las siguientes secciones. La Seccion 2 describe los atributos de calidad y la importancia de ´ en internet. En la Seclos sistemas de informacion ´ 3 se describe la metodolog´ıa que proponemos cion ´ para evaluar el sistema de informacion. As´ı mismo, ´ se describe el proceso de modelado en esta seccion ´ ´ que seguireestocastico y el proceso de evaluacion ´ 4 se mos en la metodolog´ıa propuesta. En la Seccion decribe un caso de estudio que nos permitira´ evaluar ´ 5 exnuestra metodolog´ıa. Finalmente en la Seccion pondremos las conclusiones de nuestro trabajo. Correciones Confiabilidad Eficiencia
C C E
Integridad Usabilidad Mantenibilidad Pruebas Flexibilidad Portabilidad Reusabilidad Interoperabilidad
I U M
´ Representa la capacidad del sistema • Proteccion. para protegerse a si mismo de intrusiones accidentales o programadas. Sin embargo la Disponibilidad, Seguridad y Protec´ se ven afectadas por la Fiabilidad. cion Para evaluar la Fiabilidad debemos tomar en cuenta que los sistemas de software no son entidades ´ estaticas. La Fiabilidad de un sistema se complica a medida que este crece. Es posible caracterizar el comportamiento de la Fiabilidad estudiando el comportamiento de las fallas. Para lo cual podemos considerar por ejemplo el tiempo de arribo de fallos, el numero de fallos ocurrido en un tiempo determinado, ´ la media del tiempo de ocurrencia de fallas. En todos estos casos estamos afectados por variables aleatorias. Podemos realizar modelos subsecuentes del ´ comportamiento de las fallas tratandolas como parte ´ de un proceso estocastico. Cuando el software falla es necesario localizar y reparar las fallas que causan los errores del sistema.
´ en In2 Sistemas de Informacion ternet Debido a la importancia que la calidad de software en ˜ Internet ha despertado en los ultimos anos, la Conferencia Internacional de la Ingenier´ıa de Software del ˜ 2002 (ICSE 2002) se centro´ en los aspectos de ano Calidad para los Sistemas en Internet [4], [5]. En esta conferencia se concluyo´ que los criterios de calidad ´ importantes son los siguientes: mas • Fiablidad
P
• Usabilidad
F
• Seguridad
P R I
´ entre los atributos de calidad para Figura 2: Relacion un producto de software. Las marcas obscuras impli´ inversa, y las marcas claras expresan can una relacion ´ directa una relacion
1.1
• Seguridad. Representa la capacidad de que el sistema no afecte su entorno y el de quien lo utiliza.
Confiabilidad
La confiabilidad de un sistema de computo es una propiedad que implica el grado de confianza esperado por ´ adecuada del sisteparte del usuario en la operacion ma al utilizarlo. La Confiabilidad se ve afectada por cuatro espectos fundamentales [2], [3]: • Disponibilidad. Define la probabilidad de que el sistema este funcionando en un tiempo determinado. • Fiabilidad. Es la probabilidad de que el sistema funcione correctamente durante un intervalo de tiempo.
• Disponibilidad • Escalabilidad • Mantenibilidad Con lo descrito anteriormente, es posible darnos cuenta que el estudio de los atributos de calidad para sistemas de software puede ser muy extenso. Por lo tanto, en este trabajo nos centraremos en los siste´ en Internet, debido a la importanmas de informacion ˜ recientes. cia que estos han adquirido en anos ˜ La red Internet fue´ originalmente disenada para ´ de forma rapida ´ transportar informacion y eficiente a cualquier parte del mundo. As´ı mismo, la Internet fue ˜ ´ mediante una disenada para presentar informacion, apariencia sencilla, con sitios (o portales) sin una complejidad significativa, ya que su contenido era primordialmente de texto e hiperv´ınculos. Sin embargo, a medida que fue creciendo la Internet, las aplicaciones ´ complejas y con mayores demandas se volvieron mas de Confiabilidad. Algunos ejemplos de estas aplica´ ciones son el comercio electronico, las aplicaciones
distribuidas, las Intranets, etc. Mucha de la complejidad asociada al desarrollo de aplicaciones en Internet, tiene que ver con el proceso de desarrollo elegido ´ con la integracion ´ de los elementos que las y tambien conforman. Cada d´ıa, un mayor numero de organiza´ ´ por medio de sistemas ciones manejan su informacion en Internet, por lo cual, se demanda una mayor calidad en todos los aspectos, para este tipo de sistemas de software.
Es importante mencionar que los 3 pasos de esta metodolog´ıa se utilizan actualmente en muchas industrias de software. Sin embargo, hasta donde hemos podido investigar, el primer paso no esta´ formalizado en la literatura actual, y por otro lado, ha habido poca ´ por parte de las industrias de software de divulgacion los procesos que siguen para conseguir calidad. Por ´ la contribucion ´ de este art´ıculo consiste en esta razon, ´ de la evaluacion ´ de la calidad para los la formalizacion productos de software.
3
3.1 Fases de la Metodolog´ıa
Establecimiento de la Metodolog´ıa
El objetivo de este trabajo es el desarrollo de una me´ del comportamiento del todolog´ıa para la evaluacion atributo de calidad Confiabilidad en los sistemas de ´ en Internet. informacion Los objetivos particulares de la metodolog´ıa son los siguientes: ´ y Prediccion ´ de la Calidad. 1. Evaluacion En este objetivo se pretende evaluar y predecir la calidad del producto de software mediante la ´ de metricas ´ aplicacion de software y modelos es´ tad´ısticos. Con el apoyo de las tecnicas de mo´ estad´ıstica [7] realizaremos un analisis ´ delacion del comportamiento del sistema y de sus atributos ´ de software. Los resultados de nuestro analisis ´ evaluados mediante un caso de estudio, en seran donde evaluaremos el comportamiento del sistema bajo condiciones ideales y las compararemos ´ del sistema en un contexto contra la operacion ´ seremos real. Una vez hecha esta comparacion, capaces de evaluar que tan lejos esta´ el comportamiento de nuestro sistema del funcionamiento ideal. 2. Mejora de los Procesos. En este objetivo se busca introducir el modelo PSP (Proceso de Software Personal) [6] al producto de software, en busca de mejoras del pro´ del Proceso de ceso y producto. La introduccion Software Personal en nuestra metodolog´ıa, nos permitira´ mejorar el funcionamiento del producto de software, y con ello mejorar el comportamiento de los atributos de calidad.
Las fases utilizadas en nuestra metodolog´ıa son las siguientes: ´ del atributo de calidad en el siste1. Evaluacion ma ideal. La meta en esta fase, es obtener un modelo que describa el comportamiento de los atributos de calidad para un sistema ideal. Para el funciona´ tecnicas ´ miento del sistema ideal se utilizaran de ´ ´ operando aplicasimulacion. Con la simulacion ´ y el analisis ´ remos el proceso de evaluacion que ´ 3.3. El modelo obtedescribiremos en la seccion nido servira´ de gu´ıa durante el desarrollo del producto (sistema real) de software. Es importante destacar, que los productos de software en Internet tienen caracter´ısticas y necesidades diversas, aunque el contexto de ope´ sea el mismo (la Internet). Utilizar un moracion delo ya establecido que sirva de gu´ıa para todos los productos resulta poco fiable; debido a que los requerimientos son distintos en cada producto. Por lo tanto, es necesario obtener el modelo que mejor se ajuste a las necesidades particula´ el res de cada producto de software. Ademas, modelo obtenido no sera´ el mismo para todos los atributos de calidad de software a evaluar, debido a que cada atributo evalua ´ diferentes propiedades del sistema.
En este objetivo se implementara´ un proceso de ´ de calidad y las actividades clave administracion ´ del proceso para el aseguramiento, la planeacion y el control de la calidad del producto.
´ del atributo de calidad en el siste2. Evaluacion ma real (inicial). En esta fase nuestra meta es obtener el modelo ´ cualitativa del producto que exprese la situacion de software. El sistema real, es un sistema de ´ en Internet para inscripciones en una informacion ´ del comporUniversidad. Mediante la evaluacion ´ tamiento del sistema real y del analisis de los re´ actual del atrisultados conoceremos la situacion ´ buto de calidad de interes. ´ y analisis ´ El proceso de evaluacion de los resultados para el sistema ideal y real se describe en la ´ 3.4. Seccion
Los primeros 2 pasos de esta metodolog´ıa se realizan en forma iterativa hasta que los atributos de cali´ tan cercanos al ideal como se requiera. dad esten En este art´ıculo, nos centraremos en la primera par´ te de esta metodolog´ıa, que consiste en la evaluacion ´ de la calidad del producto de software. y prediccion ´ del modelo PSP y la administraLa implementacion ´ de la calidad del producto de software estan ´ accion ´ tualmente en fase de desarrollo, por lo cual no seran descritos en este art´ıculo.
´ del Proceso de Mejora. 3. Implementacion El objetivo de esta fase es aplicar PSP (Proceso de Software Personal) al desarrollo del producto ˜ de software, con el f´ın de mejorar el desempeno de los atributos de la calidad en el producto de software. Las condiciones del ambiente de desarrollo y el tipo de producto de software influyen ´ del proceso de mejora. Ademas, ´ en la seleccion es importante tomar en cuenta como entradas las ´ necesidades de calidad de la organizacion.
´ de la Calidad. 3. Administracion
´ del sistema final. 4. Evaluacion Para cuantificar las mejoras obtenidas con la im´ del proceso de mejora (PSP) evaplementacion luaremos nuevamente el atributos de calidad del producto de software. Esperamos que el modelo resultante se acerque al comportamiento del modelo ideal. De cualquier forma, dependiendo de los requerimientos de calidad esperados se deci´ dira´ el numero de iteraciones Evaluacion-Mejora ´ necesarias. ´ 5. Analisis de los resultados y conclusiones. Despues de aplicar el proceso de mejora un numero determinado de veces, llegaremos a ob´ tener la calidad deseada en el producto de soft´ ware. En esta fase, se llevara´ a cabo un analisis de las evaluaciones obtenidas del producto de ´ y la cuantifisoftware, as´ı como la identificacion ´ de la mejoras obtenidas durante el procecacion ´ so. As´ı mismo, se llevara´ a cabo una comparacion de los objetivos planteados contra los objetivos ´ alcanzados. Este analisis debera´ registrarse en ´ bitacoras, ya que servira´ para mejorar la calidad de productos de software futuros.
3.2
´ Tecnicas de Modelado
´ Existen diversas tecnicas de modelado como son las ´ de Cadenas de Markov, Redes de Petri, Verificacion modelos (Model Checking), Modelos Estad´ısticos . • Cadenas de Markov. Es una serie de eventos en la cual la probabilidad de que ocurra un evento depende del evento inmediato anterior. Sin embargo no se recomiendan para modelar Fiabilidad, debido a que no distinguen entre los fallos seguros y los no seguros, por otro lado no toman en cuenta el proceso de restauracion o reparacion en un sistema [8]. • Redes de Petri. Son grafos orientados a la mode´ mediante nodos llamados lugares que relacion presentan estados o acciones y transiciones que representan eventos, normalmente este modela´ do se representa por conjuntos de cuadruplas. A medida que crece el sistema, el numero de nodos ´ y de transiciones aumenta y como consecuencia el numero de variables que maneja se va multipli´ cando [9]. ´ de modelos (Model Checking). Es un • Verificacion ´ formal modelo que se basa en la especificacion ´ de los modulos o programas que son representa´ con estados. Pero dos por sistemas de transicion cuando el espacio de estados es demasido grande, este enfoque resulta inapropiado [10]. • Modelos Estad´ısticos. Es un modelo orientado al ´ estudio de poblaciones (por ejemplo metricas de software). El cual se puede expresar como una ´ entre entidades a las que se les reprerelacion ´ Lo que senta mediante funciones de distribucion. ´ de una ley de probabilidad lleva a la obtencion que representa el comportamiento de los atribu´ [11]. tos de dicha poblacion
Nuestro problema radica en estudiar el comporta´ miento de la Fiabilidad en los sistemas de Informacion en Internet. En la gran mayor´ıa de los casos este tipo ´ conformados por un gran numero de sistemas estan ´ ´ de modulos. La tendencia al crecimiento en cuanto al ˜ del sistema se ve influenciada por el volumen tamano ´ que normalmente manejan. En la made informacion ˜ del sistema yor´ıa de los tipos de modelos, el tamano ´ Por otro lado es a analizar viene a ser una restriccion. importante contemplar que la metodolog´ıa se enfoca a organizaciones, por lo cual el tipo de modelo seleccionado no debe ser demasiado complicado. De acuerdo ´ ´ al anterior analisis de tecnicas de modelado conclui´ que mejor se adapta a nuestro obmos que la opcion ´ de Modelos Estad´ısticos, la cual jetivo es la obtencion describiremos a detalle y la aplicaremos a un caso de estudio.
3.3 Empleo de Modelos Estad´ısticos Los modelos estad´ısticos tienen su base en el estudio ´ es un conjunto limide poblaciones. Una poblacion tado de individuos o elementos de la misma especie ´ sometidos a un estudio estocastico. Estos elementos tienen propiedades fundamentales en comun, ´ que son ´ la base para clasificar a la poblacion. En nuestro caso, el objeto de estudio (o la pobla´ son los atributos de calidad de software. Las cion) ´ ´ metricas de software permiten evaluar a la poblacion. ´ consiste en estudiar la tendencia del Nuestro interes comportamiento de los atributos de calidad (en particular la Confiabilidad) del producto de software. Para lo cual nos proponemos evaluar y analizar el comportamiento de los atributos de calidad asociados a un producto de software mediante el estudio de su distri´ estad´ıstica. La evaluacion ´ del comportamienbucion ´ to de estos atributos la realizaremos con metricas de software, y sus resultados los describiremos mediante histogramas. El problema fundamental consiste en ´ reemplazar el histograma por una curva teorica o´ modelo que represente una ley de probabilidad. Esta ley ´ de probabilidad sera´ la imagen definitiva de la pobla´ de las metricas ´ cion de software estudiadas, y permi´ describir el comportamiento del atributo de calitiran dad. El procedimiento para obtener el modelo estad´ıstico consiste de los siguientes pasos. 1. Escoger el tipo de ley de probabilidad que nos ´ proponemos asociar a la poblacion. Esta ley podr´ıa tener un origen puramente emp´ırico; por ejemplo, el histograma de los errores que ocurren ´ de un durante un lapso de tiempo en la operacion producto de software. Ejemplos de estas leyes ´ de Weibull, la Normal, podr´ıan ser, la distribucion la de Poisson, o la Gamma. ´ 2. Evaluar los parametros contenidos en la ley esco´ gida. Una ley contiene parametros que dependen ´ estudiada. La modelacion ´ nos de la poblacion proporciona las expresiones para obtener el va´ lor de estos parametros para todos los modelos. 3. Comparar la ley escogida. Una vez escogido el ´ ´ tipo de ley y valorados los parametros numericos, debemos verificar que la ley esta´ de acuerdo con
3.4
´ estudiada. El resultado de la comla poblacion ´ puede ser favorable o desfavorable. Si paracion es favorable, expresar´ıa que la ley escogida re´ estudiada. De presenta fielmente a la poblacion lo contrario, ser´ıa necesario buscar otra ley que represente mejor el comportamiento de la pobla´ cion.
• El presupuesto asignado al desarrollo del producto de software. El presupuesto tiene ´ del perun impacto directo en la seleccion sonal, de los componentes utilizados y del tiempo de desarrollo del producto de software.
´ y Modelacion ´ Proceso de Evaluacion
´ de las ´ Tiempo de evaluacion. En la seleccion ´ ´ influyen las unidades de tiemmetricas tambien po necesarias para realizar las mediciones. Estas pueden unidades pueden ser unidades de tiempo ˜ de CPU, d´ıas, semanas, meses o incluso anos.
´ del producto de El proceso para realizar la evaluacion ´ ´ software, el analisis de los resultados y la modelacion se compone de los siguiente pasos. ´ de las condiciones iniciales. 1. Determinacion Cada fase tiene su enfoque para valorar las condi´ del producto de ciones del ambiente de operacion ´ software. Tomar en cuenta estas condiciones es ´ ´ Por ejembasico para el proceso de evaluacion. plo, algunas de estas condiciones podr´ıan ser: (a) las entradas del sistema, (b) sus restricciones, y (c) los servicios que proporciona el sistema. ´ del atributo de calidad y de sus 2. Seleccion ´ metricas de software. Es fundamental definir el atributo de calidad de software que pretendemos estudiar. En la selec´ del atributo influyen las necesidades prioritacion ´ en sus productos de rias de cada organizacion ´ seleccionado el atributo de software. Una vez calidad es necesario verificar su correspondiente ´ ´ de las metricas ´ metrica. En la seleccion influyen los siguientes factores: ´ ´ Tipos de metricas. Las metricas que se van a emplear dependen del atributo de calidad a evaluar y de las condiciones de desarrollo y opera´ del sistema. Los atributos de software mas ´ cion comunes son los mostrados en las Figuras 1 y 2. Para cada atributo es posible que existan va´ rios tipos de metricas de software que se pueden ´ aplicar. En algunos casos las metricas de software existentes no son aplicables al ambiente de ´ del proyecto, o estas son dif´ıciles de operacion obtener. En estos casos es posible implementar ´ ´ de acuerdo a las nornuevas metricas que estan ´ ˜ ıas mas de calidad de la organizacion. Compan´ como Motorola, IBM y Hewlett Packard han desa´ rrollado metricas que se adecuan a su marco de ´ [12]. produccion Condiciones de desarrollo. Las condiciones de desarrollo del sistema permiten describir: • Proceso de desarrollo de software utilizado. Existen distintos procesos de desarrollo como son: (a) Proceso de desarrollo en cascada, (b) Proceso evolutivo, (c) Proceso en ´ de espiral, (d) Prototipado o´ (e) Reutilizacion componentes. • El personal involucrado en el desarrollo. De´ es pendiendo del dominio de la aplicacion necesario verificar que el personal sea es´ pecialista en el area de dominio.
• Las condiciones de calidad impuestas por la ´ organizacion.
´ 3. Proceso de Medicion. ´ del software se refiere a derivar un La medicion ´ valor numerico para algun ´ atributo de un produc´ es una to de software. El proceso de medicion ´ actividad clave, ya que de este depende que los ´ resultados puedan ser fiables y faciles de evaluar. Los pasos a seguir en este proceso son los siguientes. a. Seleccionar los componentes a evaluar. b. Medir las caracter´ısticas de los componen´ tes con las metricas de software. ´ c. Identificar las mediciones anomalas. ´ d. Analizar los componentes anomalos. ´ de los resultados y seleccion ´ del 4. Evaluacion modelo. ´ del proceso de medicion ´ la realiLa evaluacion zamos mediante el estudio de su distribucio´ es´ pertad´ıstica. Los resultados de esta evaluacion miten analizar el conjunto de datos obtenidos me´ diante graficas conocidas como histogramas (los cuales pueden obtenerse mediante herramientas como Arena). Los histogramas permiten repre´ sentar los valores de la metrica contra su frecuen´ una aproximacia. Estos histogramas nos daran ´ al tipo de modelo que mejor se ajusta al comcion portamiento de los resultados obtenidos. Nos interesa reemplazar el histograma por una ley de probabilidad que mejor represente este comportamiento. Esta ley de probabilidad sera´ el reflejo ´ de metricas ´ del comportamiento de la poblacion estudiadas. La ley escogida nos podra´ indicar si ´ fue correctamente realizada. nuestra evaluacion ´ de los parametros ´ 5. Estimacion del modelo. ´ 3.3, esta actividad es De acuerdo a la seccion ´ del modelo. parte fundamental en la obtencion ´ del modelo se usan diversas Para la obtencion ´ ´ ´ ´ tecnicas de metodos numericos, como el metodo de los MLEs (maximun - likelihood estimators), el ´ ´ pometodo de los m´ınimos cuadrados, regresion linomial, entre otras. En ocasiones, es necesario ´ aplicar varios metodos para llegar a resultados ´ confiables, y dependiendo del parametro a esti´ mar algunos metodos son mas adecuados que otros.
´ de los parametros ´ 6. Sustitucion obtenidos y ´ del modelo resultante. graficacion ´ Una vez obtenidos los parametros resultantes, ´ estos son graficados a f´ın de observar su tenden´ cia. La grafica obtenida representa el comportamiento del atributo de calidad.
principales: (a). Investigadores/Profesores, (b) Alumnos, (c) Publico en general. El acceso al sistema es ´ con usuario y password. Cada usuario del sistema tendra´ acceso a distintos servicios que proporciona el sistema. En general se pretende que el sistema provea los servicios de altas de cursos calificaciones y alumnos, con sus respectivas bajas y modificaciones.
´ del modelo escogido. 7. Validacion ´ Con los parametros obtenidos debemos verificar que el modelo, tal y como fue´ construido esta´ de ´ de metricas ´ acuerdo con la poblacion estudiada. Por lo tanto en este proceso, se realiza una com´ de los valores que se obtienen con el paracion histograma contra los resultados que se obtienen con el modelo. ´ de las predicciones del atributo de 8. Realizacion calidad. En este proceso, las predicciones del atributo de ´ del calidad se realizan mediante la observacion modelo (o ley de probabilidad) obtenido. Con es´ de representar el comportate modelo, ademas miento de los atributos de calidad, es posible tam´ predecir el comportamiento a futuro de estos bien atributos.
4
Caso de Estudio
´ describiremos mediante un caso de En esta seccion estudio las dos primeras fases de la metodolog´ıa. En nuestro caso de estudio, evaluaremos un sistema de inscripciones v´ıa Internet (SIV) para una Universidad. La arquitectura del sistema consiste en una plataforma Linux (Redhat v.8), un manejador de bases de datos (MySQL [13]), un servidor Web (Apache [14]). El lenguaje utilizado para las interfaces de usua´ rio fue (PHP [15]). El numero de l´ıneas de codigo utili´ ´ del sistema fue de 1200. zadas en la implementacion El tiempo empleado para el desarrollo del sistema y ´ ha sido de 6 meses aproximade su documentacion damente. El diagrama a bloques de sistema se puede observar el la Figura 3. Alta de claves de acceso al sistema
Acceso al sistema
Vista del público en general Vista de los alumnos
Establecimiento del perfil Información de cursos
Información de cursos de alumnos
Vista de los investigadores
Información personal de los alumnos
Consultas
Altas
Bajas
Control del periodo de cambios
Cambios
´ Figura 3: Modulos que conforman el Sistema de Infor´ via Internet (SIV) macion
4.1
Planteamiento del Problema
Se trata de un Sistema de Inscripciones v´ıa Internet para una Universidad, en donde existen tres vistas
´ del comporta4.2 Fase 1: Determinacion miento ideal de la Fiabilidad En esta fase, se evaluara´ y modelara´ el comportamiento del sistema bajo condiciones ideales, aplican´ 3.3. do el proceso definido en la Seccion ´ de las condiciones iniciales 1. Determinacion para el caso ideal. ´ son las siLas condiciones para la simulacion guientes: El tiempo entre arribos de los usuarios al sistema ´ exponense presenta siguiendo una distribucion cial con una media µ = 5 unidades de tiempo. El tiempo que permanece cada usuario utilizando ´ normal con una el sistema posee una distribucion media µ = 5 unidades de tiempo y una varian´ del arribo de usuarios za σ = 3. La modelacion se hace mediante colas, para lo cual se utilizo´ un servidor de colas del tipo M/M/1 en el pool del servidor web 1 con una probabilidad de (n + 1)−1 , ˜ actual de la cola donde n representa el tamano ´ (numero de usuarios en el sistema). La condicion ´ de salida del sistema para cualquier usuario se presenta, (a) cuando se genera un error del usua´ del sistema, y (b) cuando rio durante la operacion el usuario solicita su salida del sistema. Por razones de fiabilidad, en cuanto a la capacidad del servidor Web y la del manejador de la Base de Datos, el sistema puede trabajar adecuadamente hasta con k usuarios (donde k = 100). Dependiendo de su vista, los usuarios pueden realizar solo x tipos de transacciones, con t unidades ´ de tiempo para realizar cada transaccion. Donde x depende de la vista, y t sigue una distribu´ normal con una media µ = 5 y una variancion za σ = 3. El problema consiste en determinar el numero de errores que se generan en el sistema ´ en un lapso de tiempo determinado. El acceso de ´ correslos usuarios y las vistas de informacion pondiente a cada perfil. ´ empleado para la siEl lenguaje de programacion ´ fue´ Java. mulacion ´ En la simulacion se emplea un modelo productor − consumidor, en donde la infor´ se maneja mediante una cola de recursos macion ´ del productorcompartidos. La sincronizacion ´ consumidor se realizo´ mediante la sincronizacion ´ de generar de hilos. El productor tienen la funcion los datos de salida para el consumidor, de acuer´ do al funcionamiento del modelo logico descrito ´ del consumidor es en la Figura 4. La funcion 1 De acuerdo a la Notacion ´ de Kendal [7], en la notacion ´ A/B/s, ´ de los tiempos entre arribos, B es la A se refiere a la distribucion ´ de los tiempos de servicio y s representa el numero distribucion ´ ´ comunes son M (Markov, o de servidores. Las distribuciones mas exponencial), G (general), y D (determinista, o constante).
2. Rutina de Incialización
1. Proceso_SIV
Establece el número de sesiones para cualquier tipo de usuario
3. arrive() Llama a la rutina de inicialización.
Inicializa las estructuras, variables del sistema y los contadores estadisticos
Establece el hilo de ejecución
Calcula el tiempo de arribo y el perfil del primer usuario
Hay peticiones en el pool?
Si
No
5. departure() Disminuye el tiempo de todos los usuarios Verifica quién finalizó su tiempo y tiene que salir de la sección No
Calcula el tiempo del siguiente arribo
Acabó el tiempo del usuario? No
No
Si
Si
Es la ultima seccion?
Hay espacio en la Si sig. sección? No Es la primera sección? No
Calcula la probabilidad de que se quede
¿Existe algún arribo?
Llama a la función arrive()
Asigna la estructura del usuario acorde a su perfil
Si Sale del sistema
Si
Disminuye en 1
Se queda en la cola del pool?
Aumenta el número de abandonos
Envia los datos a la cola de recursos compartidos
El tiempo de simulación llegó a su fin?
No No
Si
la cola del pool
No
El servidor tiene capacidad para otro usuario?
Si
Aumenta el tamaño de la cola
Si
Fin
Regresa a la función AddDepature()
4. AddDeparture() Llama a la funcion departure() No
Aumenta la cola en el pool del servidor WEB
Llama a la función AddDeparture()
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 ´ cada unidad de tiempo, de acuerdo a simulacion ´ de la los datos que el productor le env´ıa a traves ´ cola de recursos compartidos. La interfaz grafica que se muestra en la Figura 5 se desarrollo´ con el fin de visualizar el comportamiento del productor-comsumidor. ´ del proEl diagrama a bloques de la operacion ductor se muestra en la Figura 4. En este diagra´ ´ ma se pueden apreciar 5 modulos. En el modulo principal, Proceso del SIV, se ejecuta el ciclo de ´ El segundo modulo ´ ejecuciones de la simulacion. ´ tiene la funcion ´ de inicialiRutina de Inicializacion zar las estructuras, los contadores estad´ısticos y ´ de programar el primer arribo. El tercer modulo, arrive(), calcula el tiempo de arribo de los usuarios, verifica si los usuarios se quedan en la cola del pool del servidor Web y verifica si el sistema ´ usuarios. En el caso tiene capacidad para mas de que el sistema tenga suficiente capacidad, se le permite el acceso al usuario y se realiza una ´ Addeparture(). En el cuarto llamada a la funcion ´ modulo, AddDeparture(), se realiza un llamada al ´ departure() y se verifica la generacion ´ la funcion ´ simulada. En el de errores durante la operacion caso de que hallan existido errores, se aumenta la densidad de defectos y se le programa al usuario ´ su salida del sistema. El quinto modulo, departure(), se encarga de programar los tiempos de ´ o parte salida para cada usuario para la seccion del sistema que esta´ utilizando.
´ ´ del SisteFigura 5: Interface grafica de la simulacion ´ via Internet ma de Informacion ´ del atributo de calidad y de sus 2. Seleccion ´ metricas de software. El atributo que nos interesa medir es la Fiabilidad. Como se menciona anteriormente, la Fiabilidad nos permite evaluar que tan libre de fallos se encuentra un sistema. ´ Tipos de metricas. En nuestro caso nos interesa medir el atributo de ´ del producto de softwaFiabilidad en la operacion ´ re. Las metricas que son posibles utilizar para la fiabilidad son[12]: • densidad de defectos. La densidad de de´ fectos es una metrica de calidad que se define como el numero de errores que ocurren ´
D. Defec 0 1 2 3 4 5 6 7 8 9 10
durante un lapso de tiempo determinado. • media de ocurrencia de fallos. Se refiere al promedio del tiempo que tarda en produ´ de un procirse un fallo durante la operacion ducto de software. ´ En nuestro caso utilizaremos la metrica de densidad de defectos. Condiciones de desarrollo. Para el caso ideal, como se comenta anteriormente, se desarrollo´ un simulador del sistema de Inscripciones por Internet en lenguaje Java. Las condiciones de opera´ del simulador se describen en la primera parcion ´ de las condiciones te de esta fase (determinacion iniciales para el caso ideal).
´ 3. Proceso de medicion. ´ de los componentes a evaluar. a. Seleccion ´ se disen˜ o´ para medir todos los La simulacion componentes que forman al sistema. b. Medir las caracter´ısticas de los compo´ nentes con las metricas de software. ´ En este punto como la metrica fue´ la den´ se preparo´ sidad de defectos, la simulacion para que en un marco de tiempo de 100 unidades se contabilizara´ en numero de defec´ ´ del sistos que aparecieron en la simulacion tema. ´ c. Identificar las mediciones anomalas. Por ´ que el hecho de tratarse de una simulacion trabaja con condiciones ideales las medicio´ nes anomalas fueron pocas. Se desecharon ´ 5 de 500 ejecuciones de la simulacion. solo ´ d. Identificar los componentes anomalos. Para el caso ideal no se presentaron com´ ponentes anomalos. Esto fue debido a que ´ el numero de mediciones anomalas (que fue ´ de 0.99% del 100% del total de las mediciones), y no se centro´ en algun ´ componente en particular. ´ de los resultados y seleccion ´ del 4. Evaluacion modelo. El resumen de los resultados para nuestro proce´ y seleccion ´ del modelo se muesso de evaluacion tra en la Tabla 1. Los elementos que integran el resumen son los siguientes: Densidad de defectos (D.Defec), frecuencia (Frec), valor asignado en el eje x (x),la densidad de la probabilidad (Den. ´ acumulativa Prob) y los valores de la distribucion (Dist. Acum). El histograma que corresponde a estos datos se muestra en la Figura 6. Mediante el histograma apreciamos que la tendencia de los resultados se aproxima a una distri´ (o curva) de Weibull. La curva de Weibull bucion
x 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00
Den. Prob. 0.0402 0.122 0.179 0.194 0.172 0.128 0.0824 0.0439 0.0222 0.00938 0.00347
Dist. Acum. 0.0402 0.163 0.341 0.535 0.707 0.835 0.918 0.963 0.986 0.995 0.998
Tabla 1: Resumen de los resultados obtenidos durante las evaluaciones del caso ideal
120
´ Tiempo de evaluacion.
100 80
Frecuencia
´ es el tiempo que El tiempo para cada evaluacion ´ tarda cada simulacion. Cada evaluacion se llevo a cabo en 100 unidades de tiempo (lo cual se llevo´ a cabo en aproximadamente 30 segundos ´ de tiempo de ejecucion). Se llevaron a cabo 500 evaluaciones.
Frec 27 47 84 107 86 73 40 20 7 6 3
60 40 20 0 0
2
4 6 Densidad de Defectos
8
10
Figura 6: Histograma para 500 simulaciones. es un metamodelo [7], en donde α y β son sus ´ parametros. ´ de los parametros ´ 5. Estimacion del modelo. ´ Los parametros del modelo se obtienen siguiendo ´ 3.2), de la el procedimiento descrito en la seccion siguiente forma. Escoger el tipo de ley de probabilidad que nos proponemos asociar al histograma. f (x) = αβ −α xα−1 e−(x/β)
α
(1)
´ Evaluar los parametros contenidos en la ley escogida. ´ ´ 1 se obtuvo en [7] Del analisis de la Ecuacion ´ mediante estimadores de maxima verosimilitud (maximum-likelihood estimators MLEs), las siguientes ecuaciones que permiten calcular los valores de α y β. Pn Pn α 1 i=1 lnXi i=1 X lnXi P = (2) − n α α n i=1 X µ Pn β=
i=1
Xiα
¶1/α
n
(3)
´ 2 se resuelve mediante el metodo ´ La Ecuacion ´ 3 de Newton-Rapson, mientras que la Ecuacion se obtiene de manera directa conociendo el valor ´ de α. Los valores obtenidos de los parametros a partir de las Ecuaciones 2 y 3 son: α = 2.11 y β = 4.54.
´ de los parametros ´ 6. Sustitucion obtenidos gra´ del modelo ideal fi . ficacion De acuerdo a los valores de α y β antes descritos ´ de probabilidad se calcula de la siguienla funcion te forma. ½ 2.11 5.127x1.11 e−(x/4.54) Si x ≥ 0 fi (x) = 0 En otro caso ´ La grafica del Comportamiento de la Fiabilidad de acuerdo al modelo ideal fi se presenta en la Figura 8. ´ del modelo obtenido. 7. Validacion ´ estad´ıstica, la curva De acuerdo a la modelacion de Weibull permite representar el tiempo de ocurrencia de fallos de alguna pieza de un sistema o´ equipo. Por lo cual, el hecho de que el modelo obtenido siga una curva de Weibull nos permite validar nuestro proceso. En otras palabras, pode´ mos decir que la metrica Densidad de Defectos es la adecuada para representar el comportamiento de la Fiabilidad del producto de software . ´ de las predicciones de la fiabili8. Realizacion dad. ´ proporcionada por De acuerdo a la informacion el Histograma de la Figura 6, es posible observar que la tendencia de la curva describe que la densidad de defectos presenta valores bajos con ´ se obtiene del un alta frecuencia. Esta conclusion hecho de que en la mayor´ıa de las evaluaciones se obtuvo un bajo numero de errores. ´
4.3
´ de la fiabilidad en Fase 2:Evaluacion el sistema real siguiendo Proceso de ´ y modelacion ´ evaluacion
´ de las condiciones iniciales 1. Determinacion para el caso real. Las condiciones del proceso fueron las siguien´ tes. Las evaluaciones fueron hechas por un solo usuario, el cual tomo el rol de tres tipos de vistas: alumnos, investigadores y publico en general. La ´ forma de realizar las transacciones sobre el Sis´ en Internet fue´ de manera tema de Informacion aleatoria para cada rol, mediante una matriz de pruebas. La matriz de pruebas conten´ıa los distintos servicios y los datos requeridos a accesar del sistema. Esta matriz estuvo compuesta de op´ ´ ciones validas y opciones no-validas. Los datos de prueba fueron tomados de manera aleatoria ´ de la matriz de pruebas, para cada evaluacion. ´ en el sistema fueLas condiciones de operacion ron las siguientes: • El tiempo entre arribos (de cada usuario) fue´ de 100 minutos. • El servidor Web opero´ con un solo procesador de 500 Mhz. • La capacidad del servidor Web y la del manejador de la Base de Datos con la cual pueden operar adecuadamente el sistema (de acuerdo a los estandares del proveedor redhat) es de hasta 100 usuarios.
´ • Dependiendo de su vista, los usuarios solo pueden realizar un numero limitado de tran´ sacciones. ´ se Los resultados obtenidos en cada evaluacion ´ almacenaron en bitacoras, y se promediaron con el f´ın de graficar los histogramas. ´ de los atributos a medir y de sus 2. Seleccion ´ metricas. ´ Tipos de metricas. Al igual que en caso ideal, ´ el atributo a evaluar es la Fiabilidad y la metrica para dicho atributo sera´ la densidad de defectos. Condiciones de desarrollo. En el Sistema de Inscripciones por Internet seguimos el modelo de desarrollo en cascada. En el desarrollo de este sistema intervinieron dos personas especialistas en el desarrollo de sistemas en Internet y el tiempo de desarrollo fue de 6 meses. ´ Tiempo de evaluacion. ´ de cada experimento El tiempo para la evaluacion fue de 100 unidades de tiempo (lo cual se llevo a cabo en un lapso de 100 minutos). El numero de ´ experimentos para el caso ideal fue de 500 mientras que para el caso real fue de 70. Esto se debio´ a que los 70 experimentos fueron llevados a cabo en 3 semanas. Para lograr realizar 500 evaluaciones hubieran sido necesarios varios meses de ´ del proceso de evaluacion. ´ ejecucion ´ 3. Proceso de medicion. ´ de los componentes a medir. a. Seleccion ´ del sistema real se miDurante la operacion dieron todos los componentes que forman al sistema. b. Medir las caracter´ısticas de los compo´ nentes con las metricas de software. ´ En este punto la metrica utilizada fue´ la densidad de defectos. Durante cada experimento se contabilizo´ el numero de defectos ocu´ rridos. ´ c. Identificar las mediciones anomalas. Du´ del sistema no ocurrieron rante la ejecucion ´ mediciones anomalas. ´ d. Identificar los componentes anomalos. Los errores que encontramos con mayor frecuencia en los componentes seleccionados ´ del sistema son los sidurante la operacion guientes: Periodo de Inscripciones: ´ • No se actualiza automaticamente la fecha. Alta de CURSOS: ´ • No reconoce automaticamente la sec´ a la que pertenece la persona que cion da de alta el curso. ´ an• No valida totalmente la informacion ´ en la Base tes del proceso de insercion de Datos. Alta de cursos por alumno:
D. Defec 0 1 2 3 4 5 6 7 8 9 10 11
Frec 5 20 15 8 9 1 1 2 1 1 2 5
x 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00 11.00 12.00
Den. Prob. 0.234 0.179 0.137 0.105 0.0805 0.0616 0.0472 0.0361 0.0277 0.0212 0.0162 0.0124
Dist. Acum. 0.234 0.414 0.551 0.657 0.737 0.799 0.846 0.882 0.910 0.931 0.947 0.959
α = 1.32 y β = 4.1 Al igual que en caso ideal, los valores de α y β se resuelven de acuerdo a las Ecuaciones 2 y 3. ´ de los parametros ´ 6. Sustitucion obtenidos fr y ´ del modelo real. graficacion ´ Sustituyendo los valores de α y β en la funcion ´ del modelo real fr nos da la siguiente expresion. ½ 1.32 3.67x0.32 e−(x/4.1) Si x ≥ 0 fr (x) = 0 En otro caso
Tabla 2: Resumen de los resultados obtenidos durante las evaluaciones del caso real • Permite registrar mas de 4 cursos por alumno. Consulta de cursos por alumno: • No se presenta la lista completa de los alumnos que asesora un investigador/profesor. Alta de alumnos: ´ an• No valida totalmente la informacion ´ en la Base tes del proceso de insercion de Datos. ´ de los resultados y seleccion ´ del 4. Evaluacion modelo. El resumen de los datos obtenidos durante las 70 evaluaciones se presenta en la Tabla 2. Al igual que en el caso ideal en la tabla se registran los siguientes valores: Densidad de defectos (D.Defec), frecuencia de ocurrencia (Frec), la re´ en x (x), la densidad de probabilidad presentacion ´ acumulativa (Dist. (Den. Prob.) y la distribucion Acum.). El histograma resultante se presenta en la Figura 7.
´ La grafica del comportamiento de la Fiabilidad de acuerdo al modelo real fr se presenta en la Figura 8. ´ del modelo obtenido. 7. Comparacion Es posible observar que el modelo obtenido pa´ de Weibull. ra el caso real sigue una distribucion El modelo obtenido sigue en contexto con el concepto de Densidad de Defectos, por lo que no se opone a representar el comportamiento de la Fiabilidad real. ´ de las predicciones de la fiabili8. Realizacion dad. ´ de los En la Figura 8 se observa la comparacion modelos resultantes (ideal y real) de las evalua´ ciones del caso de estudio. Los parametros αyβ ´ que existe representan el grado de aproximacion entre los modelos ideal y real. Para obtener un producto de software con un buen nivel de fiabilidad se debe cumplir lo siguiente. αr → αi y βr → βi Es posible observar en la Figura 8 que el comportamiento obtenido del modelo real esta´ alejado del comportamiento del modelo ideal. Esto se ´ de que: puede derivar de la observacion
20
αr 6= αi y βr 6= βi ⇒ fr (x) 6= fi (x).
Frecuencia
15
Por lo tanto, concluimos que son necesarias mejoras en el producto de software, para lo cual sera´ ´ de la segunda parte de la necesaria la ejecucion metodolog´ıa, que consiste en el proceso de mejora PSP.
10
5
0 0
2
4 6 8 Densidad de Defectos
10
12
Modelo ideal fi(x) Modelo real fr(x)
14 12
Figura 7: Histograma para 70 mediciones de errores
´ de los parametros ´ 5. Estimacion del modelo. ´ de densidad utilizada para modelar el La funcion caso real es la siguiente.
10
f(x)
Mediante el histograma apreciamos que la tendencia que presentan los datos describe una curva de Weibull.
8 6 4 2 0 0
α
f (x) = αβ −α xα−1 e−(x/β)
(4)
´ en donde, los parametros α y β obtenidos son los siguientes.
2
4
6
8
10
12
14
x
´ Figura 8: Grafica del modelo ideal y real para el caso de estudio
5
Conclusiones
En este trabajo se formulo´ una metodolog´ıa para la ´ de sistemas de informacion ´ en internet. EL validacion atributo de calidad que se analizo´ fue la fiabilidad. Se pretende que esta metodolog´ıa pueda ser aplicada a ´ a los sistecualquier sistemas de software, y no solo mas de software en Internet. Es claro que un buen ´ ´ imporanalisis de calidad es una de las bases mas tantes para la toma desiciones dentro de una orga´ que desarrolla software de calidad. Por tal nizacion ´ la evaluacion ´ de un producto de software perrazon, mitira´ mejorar el control de la calidad de un producto de software. ´ En nuestro trabajo hemos aplicado la modelacion estad´ıstica para predecir del comportamiento de los atributos de calidad de un sistema de software. Me´ de un caso de estudio, hemos diante la evaluacion concluido que la metodolog´ıa desarrollada es una herramienta eficiente dentro del proceso de desarrollo de software. Esta herramienta permite controlar la calidad del proceso y del producto de software resultante. ´ lograr El uso de esta metodolog´ıa permitira´ tambien ´ de costos en el sistema de software y una reduccion ´ de su proceso de su desarrollo. tambien ´ fue ejecutada en su La metodolog´ıa propuesta solo ´ y prediccion ´ de la calidad primer fase de evaluacion del producto de software. Como trabajo futuro nos proponemos ejecutar completa nuestra metodolog´ıa ´ incluyendo el proceso de mejora PSP y su evaluacion iterativa, con el f´ın de mejorar los objetivos de calidad. Adicionalmente, nos proponemos estudiar otros criterios 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 Engineering Institute. Model checking and abstraction. ACM Transactions 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 Engineering, Second Edition. Addison - Wesley, 2003. [13] http:// www.mysql.com [14] http:// www.apache.org [15] http:// www.php.com
[16] J. Raj. The Art of Computer Systems Performance Analisys. ISBN 0-471-50336-3. John Wiley and Sons, 1991.