Calidad en el Desarrollo Software Basado en Componentes - Historial de revisiones

Josefina: Texto reemplazado: «
» por «»

2019-07-29T08:55:39Z

Texto reemplazado: «<div align="justify">» por «»

Eralarcon jc.bayamo1 en 22:29 13 sep 2013

2013-09-13T22:29:04Z

Leydis jc.manzanillo4 en 22:01 6 oct 2011

2011-10-06T22:01:40Z

Leydis jc.manzanillo4 en 21:50 6 oct 2011

2011-10-06T21:50:10Z

Diamela jc.bayamo8 en 17:00 6 oct 2011

2011-10-06T17:00:04Z

Diamela jc.bayamo8: /* Fuente. */

2011-10-06T16:47:55Z

‎Fuente.

Eralarcon jc.bayamo1: /* Otras características. */

2011-10-03T18:11:56Z

‎Otras características.

Eralarcon jc.bayamo1 en 18:09 3 oct 2011

2011-10-03T18:09:35Z

Eralarcon jc.bayamo1: /* Fuente. */

2011-10-03T18:05:24Z

‎Fuente.

Eralarcon jc.bayamo1: /* Otras características. */

2011-10-03T18:04:41Z

‎Otras características.

@@ Línea 5: / Línea 5: @@
 |concepto=El  desarrollo de software basado en componentes se ha convertido  actualmente en uno de los mecanismos más efectivos para la construcción  de grandes sistemas y aplicaciones de [[software]]. Una vez que la mayor  parte de los aspectos funcionales de esta disciplina comienzan a estar  bien definidos, la atención de la comunidad científica comienza a  centrarse en los aspectos extra-funcionales y de [[calidad]], como un  paso hacia una verdadera [[ingeniería]].
 }}
-<div align="justify">
 '''Calidad  en el Desarrollo Software Basado en Componentes'''. La palabra calidad  tiene varios significados, aunque dentro de la Ingeniería del  [[Software]] podemos adoptar la definición de la norma ISO-8402, que  luego se repite en otras (por  ejemplo en ISO-14598): “La totalidad  de aspectos y características de un producto o servicio que  tienen que ver con su habilidad para satisfacer las necesidades  declaradas o implícitas”. Aunque la calidad es un objetivo importante  para cualquier producto, no debemos  olvidar que los productos, y  también los productos [[software]], se construyen para ser utilizados.

@@ Línea 1: / Línea 1: @@
 {{Definición
 |nombre=Calidad en el Desarrollo Software Basado en Componentes
-|imagen=Calidad_de_coomponentes.jpg‎
+|imagen=Calidad_de_SWBC.jpg
 |tamaño=
 |concepto=El  desarrollo de software basado en componentes se ha convertido  actualmente en uno de los mecanismos más efectivos para la construcción  de grandes sistemas y aplicaciones de [[software]]. Una vez que la mayor  parte de los aspectos funcionales de esta disciplina comienzan a estar  bien definidos, la atención de la comunidad científica comienza a  centrarse en los aspectos extra-funcionales y de [[calidad]], como un  paso hacia una verdadera [[ingeniería]].

@@ Línea 6: / Línea 6: @@
 }}
 <div align="justify">
-'''Calidad  en el Desarrollo Software Basado en Componentes'''. La palabra calidad  tiene varios significados, aunque dentro de la [[Ingeniería del  Software]] podemos adoptar la definición de la norma ISO-8402, que  luego se repite en otras (por  ejemplo en ISO-14598): “La totalidad  de aspectos y características de un producto o servicio que  tienen que ver con su habilidad para satisfacer las [[necesidades]]  declaradas o implícitas”. Aunque la calidad es un objetivo importante  para cualquier producto, no debemos  olvidar que los productos, y  también los productos [[software]], se construyen para ser utilizados.
+'''Calidad  en el Desarrollo Software Basado en Componentes'''. La palabra calidad  tiene varios significados, aunque dentro de la Ingeniería del  [[Software]] podemos adoptar la definición de la norma ISO-8402, que  luego se repite en otras (por  ejemplo en ISO-14598): “La totalidad  de aspectos y características de un producto o servicio que  tienen que ver con su habilidad para satisfacer las necesidades  declaradas o implícitas”. Aunque la calidad es un objetivo importante  para cualquier producto, no debemos  olvidar que los productos, y  también los productos [[software]], se construyen para ser utilizados.
-Por  tanto, el principal objetivo de un producto es satisfacer una necesidad  (o varias) de un [[usuario]] y, por consiguiente, ofrecer al usuario  algún beneficio por su  utilización. Es decir, la calidad no es el  objetivo último del producto, sino satisfacer las necesidades de un  [[cliente]]. También es importante señalar que esto implica que la  calidad de un producto software no se puede referir únicamente a obtener  un producto sin [[errores]]. La especificación de la calidad del  software debe ser más detallada y exacta, y el camino para ello es la  formalización de la calidad mediante un  [[modelo de calidad]] que, como  veremos a continuación, define las [[características]] de un producto  que influyen a la hora de medir su calidad.
+Por  tanto, el principal objetivo de un producto es satisfacer una necesidad  (o varias) de un [[usuario]] y, por consiguiente, ofrecer al usuario  algún beneficio por su  utilización. Es decir, la calidad no es el  objetivo último del producto, sino satisfacer las necesidades de un  [[cliente]]. También es importante señalar que esto implica que la  calidad de un producto software no se puede referir únicamente a obtener  un producto sin errores. La especificación de la calidad del  software debe ser más detallada y exacta, y el camino para ello es la  formalización de la calidad mediante un  [[modelo de calidad]] que, como  veremos a continuación, define las características de un producto  que influyen a la hora de medir su calidad.
 == Características de Calidad en Componentes ==
-En  general, no existe un consenso a la hora de definir y clasificar las  características de calidad que debe presentar un producto software. Por  tanto, utilizaremos los [[ estándares]] internacionales,  fundamentalmente el [[ISO-9126]]. Aunque actualmente en [[proceso]] de  revisión, ha sido el primero en definir y concretar este tipo de  características.
+En  general, no existe un consenso a la hora de definir y clasificar las  características de calidad que debe presentar un producto software. Por  tanto, utilizaremos los  estándares internacionales,  fundamentalmente el ISO-9126. Aunque actualmente en [[proceso]] de  revisión, ha sido el primero en definir y concretar este tipo de  características.
-Siguiendo su terminología,  entendemos por  característica de calidad de un producto software a un  [[conjunto]] de [[propiedades]] mediante las cuales se evalúa y describe  su calidad. Una característica se puede refinar en múltiples niveles de   sub-características. Ejemplos de características son la  [[funcionalidad]], la [[fiabilidad]] o la [[facilidad]] de uso. A su  vez, la característica funcionalidad se puede descomponer en  sub-características como corrección, interoperatividad y seguridad,  entre otras.
+Siguiendo su terminología,  entendemos por  característica de calidad de un producto software a un  [[conjunto]] de propiedades mediante las cuales se evalúa y describe  su calidad. Una característica se puede refinar en múltiples niveles de   sub-características. Ejemplos de características son la  funcionalidad, la fiabilidad o la facilidad de uso. A su  vez, la característica funcionalidad se puede descomponer en  sub-características como corrección, interoperatividad y seguridad,  entre otras.
-Llamaremos [[atributo]] a una  propiedad de calidad a la que puede asignársele una [[ métrica]],  entendiendo por métrica un procedimiento que examina un [[componente]] y  produce un dato simple, un símbolo (p.e. Excelente, Sí, No) o un  número. Hay que tener en cuenta que no todas las propiedades son  medibles (p.e. la “demostrabilidad”).
+Llamaremos atributo a una  propiedad de calidad a la que puede asignársele una métrica,  entendiendo por métrica un procedimiento que examina un componente y  produce un dato simple, un símbolo (p.e. Excelente, Sí, No) o un  número. Hay que tener en cuenta que no todas las propiedades son  medibles (p.e. la “demostrabilidad”).
-Con todo  esto, un  modelo de calidad se  define como “un conjunto de  características y sub-características, junto con las [[relaciones]] que  existen entre ellas”. Por supuesto, el modelo de calidad a utilizar va a  depender del tipo de producto a evaluar. En este sentido, los  estándares y propuestas  existentes definen modelos de calidad  generales, válidos para grandes familias de productos. Sin embargo, su  alto grado de generalización y abstracción hacen difícil su aplicación a  temas concretos. También, es importante tratar de “[[refinar]]” esos  modelos generales, particularizándolos a casos concretos. Por ello,  resultaría de gran interés y utilidad poder contar con un modelo de  calidad particularizado para componentes. Desde nuestro punto de vista,  dicho modelo de calidad ha de ser simple y concreto si queremos que  pueda ser utilizado con ciertas garantías de [[éxito]].
+Con todo  esto, un  modelo de calidad se  define como “un conjunto de  características y sub-características, junto con las relaciones que  existen entre ellas”. Por supuesto, el modelo de calidad a utilizar va a  depender del tipo de producto a evaluar. En este sentido, los  estándares y propuestas  existentes definen modelos de calidad  generales, válidos para grandes familias de productos. Sin embargo, su  alto grado de generalización y abstracción hacen difícil su aplicación a  temas concretos. También, es importante tratar de “refinar” esos  modelos generales, particularizándolos a casos concretos. Por ello,  resultaría de gran interés y utilidad poder contar con un modelo de  calidad particularizado para componentes. Desde nuestro punto de vista,  dicho modelo de calidad ha de ser simple y concreto si queremos que  pueda ser utilizado con ciertas garantías de éxito.
-Uno  de los principales objetivos de tal modelo de calidad para componentes  es el de detectar los atributos que pueden describir los [[proveedores]]  (externos o internos) de componentes [[COTS]] en la información que  suministran acerca de los mismos y que, por tanto, permitirían facilitar  su valoración y selección por parte de los diseñadores y  desarrolladores de productos software.
+Uno  de los principales objetivos de tal modelo de calidad para componentes  es el de detectar los atributos que pueden describir los proveedores  (externos o internos) de componentes COTS en la información que  suministran acerca de los mismos y que, por tanto, permitirían facilitar  su valoración y selección por parte de los diseñadores y  desarrolladores de productos software.
 == Clasificación de los atributos de calidad==
-Para  los componentes, y tendiendo en cuenta como posible objetivo la  definición de un modelo de calidad específico, es fundamental primero  realizar una [[taxonomía]], tratando de clasificar las características  de calidad de acuerdo a su naturaleza y a distintos [[parámetros]] que  intervienen en su medida. Se pueden realizar distintos tipos de  clasificaciones.
+Para  los componentes, y tendiendo en cuenta como posible objetivo la  definición de un modelo de calidad específico, es fundamental primero  realizar una [[taxonomía]], tratando de clasificar las características  de calidad de acuerdo a su naturaleza y a distintos parámetros que  intervienen en su medida. Se pueden realizar distintos tipos de  clasificaciones.
-.  En primer lugar,  necesitamos discriminar entre aquellas características que tienen  sentido para los componentes aislados (características  locales) o bien  deben ser valoradas a nivel de la [[ arquitectura]] software de la  aplicación (que llamaremos   7 características  globales). Por ejemplo,  la “[[tolerancia a fallos]]” es una típica característica que va a  depender de la arquitectura de la aplicación, mientras que la  “[[madurez]]” es más propia de los componentes.
+.  En primer lugar,  necesitamos discriminar entre aquellas características que tienen  sentido para los componentes aislados (características  locales) o bien  deben ser valoradas a nivel de la [[ arquitectura]] software de la  aplicación (que llamaremos   7 características  globales). Por ejemplo,  la “tolerancia a fallos” es una típica característica que va a  depender de la arquitectura de la aplicación, mientras que la  “[[madurez]]” es más propia de los componentes.
 .   El instante en el cual una característica puede ser observada o  medida, permite establecer otra clasificación de las características de  un producto. Así, tenemos dos posibles categorías dependiendo de si la  característica es observable en tiempo de ejecución (p.e. el  rendimiento) o durante el [[ciclo de vida]] del producto (p.e. la  mantenibilidad).
-.  Como se menciona en los  estándares de [[ISO]], es importante identificar los usuarios a los que  se dirige el modelo. En el ámbito del [[DSBC]], los usuarios son  fundamentalmente los arquitectos software, que necesitan evaluar los  componentes COTS que van a formar parte de su aplicación. Así, las  [[interfaces]] de los componentes objeto de nuestro estudio son más las  interfaces programáticas (es decir, las [[APIs]] que definen  las formas  de acceder desde otros programas a los servicios que ofrecen los  componentes), que las interfaces de usuario.
+.  Como se menciona en los  estándares de [[ISO]], es importante identificar los usuarios a los que  se dirige el modelo. En el ámbito del DSBC, los usuarios son  fundamentalmente los arquitectos software, que necesitan evaluar los  componentes COTS que van a formar parte de su aplicación. Así, las  interfaces de los componentes objeto de nuestro estudio son más las  interfaces programáticas (es decir, las APIs que definen  las formas  de acceder desde otros programas a los servicios que ofrecen los  componentes), que las interfaces de usuario.
-.   Para componentes COTS, es fundamental distinguir entre métricas  internas y externas. Las internas miden los atributos internos del  producto final o de los productos intermedios (p.e. la especificación o  el código fuente) durante el [[diseño]] y la [[codificación]]. Las  externas son las que realizan las [[mediciones]] en función del  comportamiento del sistema durante las [[pruebas]] y la operación del  componente. Por tanto, debido al carácter de [[caja negra]] de los  componentes COTS, son las métricas externas las que interesan. Esto no  quita que algunas de las características internas den una medida  indirecta de las externas, e incluso que puedan tener efectos sobre la  arquitectura final. Así, por ejemplo, el tamaño de un componente puede  ser importante a la hora de tener en cuenta los requisitos de espacio de  la aplicación.
+.   Para componentes COTS, es fundamental distinguir entre métricas  internas y externas. Las internas miden los atributos internos del  producto final o de los productos intermedios (p.e. la especificación o  el código fuente) durante el [[diseño]] y la codificación. Las  externas son las que realizan las mediciones en función del  comportamiento del sistema durante las pruebas y la operación del  componente. Por tanto, debido al carácter de caja negra de los  componentes COTS, son las métricas externas las que interesan. Esto no  quita que algunas de las características internas den una medida  indirecta de las externas, e incluso que puedan tener efectos sobre la  arquitectura final. Así, por ejemplo, el tamaño de un componente puede  ser importante a la hora de tener en cuenta los requisitos de espacio de  la aplicación.
 == Otras características ==
@@ Línea 39: / Línea 38: @@
 Por  último, es importante señalar que, además de las características de  calidad en un componente, hay otro conjunto de características no  relacionadas directamente con la calidad como pueden ser el precio, la  asistencia técnica, las condiciones de licencia, etc., que también son  necesarias a la hora de valorar el componente más adecuado.
-Todas  estas características técnicas y no técnicas deben estar documentadas  en un formato aceptado por los participantes en el desarrollo de  software. Una forma adecuada de implementar la documentación de  componentes es utilizar el modelo de “[[propiedades]]” de ODP [RM-ODP  [[1997]]] donde cada atributo se describe mediante un par (nombre,  valor), con un tipo asociado a cada nombre. Estas propiedades se pueden  describir mediante plantillas [[XML]], lo cual facilita la conexión con  cualquier tipo de herramientas. Además, esta forma de documentar los  componentes abre la posibilidad de implementar procesos de selección  automática o semiautomática, facilitando el proceso de valoración de los  componentes software.
+Todas  estas características técnicas y no técnicas deben estar documentadas  en un formato aceptado por los participantes en el desarrollo de  software. Una forma adecuada de implementar la documentación de  componentes es utilizar el modelo de “propiedades” de ODP [RM-ODP  [[1997]]] donde cada atributo se describe mediante un par (nombre,  valor), con un tipo asociado a cada nombre. Estas propiedades se pueden  describir mediante plantillas [[XML]], lo cual facilita la conexión con  cualquier tipo de herramientas. Además, esta forma de documentar los  componentes abre la posibilidad de implementar procesos de selección  automática o semiautomática, facilitando el proceso de valoración de los  componentes software.
-Otro tema, muy  relacionado con este, es  el de la [[Calidad de Servicio]] (QoS). En su  normativa, ISO define la [[QoS]] como “un conjunto de calidades  relacionadas con el comportamiento colectivo de uno o más objetos”. En  este sentido es importante señalar que fundamentalmente este tipo de  atributos van  a coincidir con los atributos de calidad que  pueden ser  medidos durante la ejecución del sistema o de los componentes. Sin  embargo, suelen ser más al nivel de sistema que de componentes, pues la  QoS se mide con respecto al comportamiento global del sistema y a los  resultados que éste produce.
+Otro tema, muy  relacionado con este, es  el de la Calidad de Servicio (QoS). En su  normativa, ISO define la QoS] como “un conjunto de calidades  relacionadas con el comportamiento colectivo de uno o más objetos”. En  este sentido es importante señalar que fundamentalmente este tipo de  atributos van  a coincidir con los atributos de calidad que  pueden ser  medidos durante la ejecución del sistema o de los componentes. Sin  embargo, suelen ser más al nivel de sistema que de componentes, pues la  QoS se mide con respecto al comportamiento global del sistema y a los  resultados que éste produce.
-Por tanto, no es  suficiente con disponer de los valores de los atributos de calidad de  los componentes de un sistema, sino también influye la forma en la que  están conectados, el medio de transporte que utilizan para  comunicarse,  la complejidad de los protocolos de interacción entre ellos, etc. En  general este es un tema complejo y en el cual se trabaja de forma muy  activa [[Pal]] et al., [[2000]]; [[Cukier]] et al., [[1998]];  [[Schmitdt]] et al., 1998; [[Zinky]] et al., [[1997]].
+Por tanto, no es  suficiente con disponer de los valores de los atributos de calidad de  los componentes de un sistema, sino también influye la forma en la que  están conectados, el medio de transporte que utilizan para  comunicarse,  la complejidad de los protocolos de interacción entre ellos, etc. En  general este es un tema complejo y en el cual se trabaja de forma muy  activa Pal et al., [[2000]]; Cukier et al., [[1998]];  Schmitdt et al., [[1998]]; Zinky et al., [[1997]].
 == Fuente ==

@@ Línea 3: / Línea 3: @@
 |imagen=Calidad_de_coomponentes.jpg‎
 |tamaño=
-|concepto=El  desarrollo de software basado en [[componentes]] se ha convertido  actualmente en uno de los mecanismos más efectivos para la construcción  de grandes sistemas y aplicaciones de [[software]]. Una vez que la mayor  parte de los aspectos funcionales de esta disciplina comienzan a estar  bien definidos, la atención de la comunidad científica comienza a  centrarse en los aspectos extra-funcionales y de [[calidad]], como un  paso hacia una verdadera [[ingeniería]].
+|concepto=El  desarrollo de software basado en componentes se ha convertido  actualmente en uno de los mecanismos más efectivos para la construcción  de grandes sistemas y aplicaciones de [[software]]. Una vez que la mayor  parte de los aspectos funcionales de esta disciplina comienzan a estar  bien definidos, la atención de la comunidad científica comienza a  centrarse en los aspectos extra-funcionales y de [[calidad]], como un  paso hacia una verdadera [[ingeniería]].
 }}
 <div align="justify">
-'''Calidad  en el Desarrollo Software Basado en Componentes'''. La palabra calidad  tiene varios significados, aunque dentro de la [[Ingeniería del  Software]] podemos adoptar la definición de la norma [[ISO-8402]], que  luego se repite en otras (por  ejemplo en [[ISO-14598]]): “La totalidad  de aspectos y características de un [[producto]] o [[servicio]] que  tienen que ver con su habilidad para satisfacer las [[necesidades]]  declaradas o implícitas”. Aunque la calidad es un objetivo importante  para cualquier producto, no debemos  olvidar que los productos, y  también los productos [[software]], se construyen para ser utilizados.
+'''Calidad  en el Desarrollo Software Basado en Componentes'''. La palabra calidad  tiene varios significados, aunque dentro de la [[Ingeniería del  Software]] podemos adoptar la definición de la norma ISO-8402, que  luego se repite en otras (por  ejemplo en ISO-14598): “La totalidad  de aspectos y características de un producto o servicio que  tienen que ver con su habilidad para satisfacer las [[necesidades]]  declaradas o implícitas”. Aunque la calidad es un objetivo importante  para cualquier producto, no debemos  olvidar que los productos, y  también los productos [[software]], se construyen para ser utilizados.
 Por  tanto, el principal objetivo de un producto es satisfacer una necesidad  (o varias) de un [[usuario]] y, por consiguiente, ofrecer al usuario  algún beneficio por su  utilización. Es decir, la calidad no es el  objetivo último del producto, sino satisfacer las necesidades de un  [[cliente]]. También es importante señalar que esto implica que la  calidad de un producto software no se puede referir únicamente a obtener  un producto sin [[errores]]. La especificación de la calidad del  software debe ser más detallada y exacta, y el camino para ello es la  formalización de la calidad mediante un  [[modelo de calidad]] que, como  veremos a continuación, define las [[características]] de un producto  que influyen a la hora de medir su calidad.

@@ Línea 11: / Línea 11: @@
-== Características de Calidad en Componentes. ==
+== Características de Calidad en Componentes ==
 En  general, no existe un consenso a la hora de definir y clasificar las  características de calidad que debe presentar un producto software. Por  tanto, utilizaremos los [[ estándares]] internacionales,  fundamentalmente el [[ISO-9126]]. Aunque actualmente en [[proceso]] de  revisión, ha sido el primero en definir y concretar este tipo de  características.
@@ Línea 23: / Línea 23: @@
 Uno  de los principales objetivos de tal modelo de calidad para componentes  es el de detectar los atributos que pueden describir los [[proveedores]]  (externos o internos) de componentes [[COTS]] en la información que  suministran acerca de los mismos y que, por tanto, permitirían facilitar  su valoración y selección por parte de los diseñadores y  desarrolladores de productos software.
-== Clasificación de los atributos de calidad. ==
+== Clasificación de los atributos de calidad==
 Para  los componentes, y tendiendo en cuenta como posible objetivo la  definición de un modelo de calidad específico, es fundamental primero  realizar una [[taxonomía]], tratando de clasificar las características  de calidad de acuerdo a su naturaleza y a distintos [[parámetros]] que  intervienen en su medida. Se pueden realizar distintos tipos de  clasificaciones.
@@ Línea 35: / Línea 35: @@
 .   Para componentes COTS, es fundamental distinguir entre métricas  internas y externas. Las internas miden los atributos internos del  producto final o de los productos intermedios (p.e. la especificación o  el código fuente) durante el [[diseño]] y la [[codificación]]. Las  externas son las que realizan las [[mediciones]] en función del  comportamiento del sistema durante las [[pruebas]] y la operación del  componente. Por tanto, debido al carácter de [[caja negra]] de los  componentes COTS, son las métricas externas las que interesan. Esto no  quita que algunas de las características internas den una medida  indirecta de las externas, e incluso que puedan tener efectos sobre la  arquitectura final. Así, por ejemplo, el tamaño de un componente puede  ser importante a la hora de tener en cuenta los requisitos de espacio de  la aplicación.
-== Otras características. ==
+== Otras características ==
 Por  último, es importante señalar que, además de las características de  calidad en un componente, hay otro conjunto de características no  relacionadas directamente con la calidad como pueden ser el precio, la  asistencia técnica, las condiciones de licencia, etc., que también son  necesarias a la hora de valorar el componente más adecuado.
@@ Línea 43: / Línea 43: @@
 Otro tema, muy  relacionado con este, es  el de la [[Calidad de Servicio]] (QoS). En su  normativa, ISO define la [[QoS]] como “un conjunto de calidades  relacionadas con el comportamiento colectivo de uno o más objetos”. En  este sentido es importante señalar que fundamentalmente este tipo de  atributos van  a coincidir con los atributos de calidad que  pueden ser  medidos durante la ejecución del sistema o de los componentes. Sin  embargo, suelen ser más al nivel de sistema que de componentes, pues la  QoS se mide con respecto al comportamiento global del sistema y a los  resultados que éste produce.
-Por tanto, no es  suficiente con disponer de los valores de los atributos de calidad de  los componentes de un sistema, sino también influye la forma en la que  están conectados, el medio de transporte que utilizan para  comunicarse,  la complejidad de los protocolos de interacción entre ellos, etc. En  general este es un tema complejo y en el cual se trabaja de forma muy  activa [[Pal]] et al., [[2000]]; [[Cukier]] et al., [[1998]];  [[Schmitdt]] et al., 1998; [[Zinky]] et al., 1997].
+Por tanto, no es  suficiente con disponer de los valores de los atributos de calidad de  los componentes de un sistema, sino también influye la forma en la que  están conectados, el medio de transporte que utilizan para  comunicarse,  la complejidad de los protocolos de interacción entre ellos, etc. En  general este es un tema complejo y en el cual se trabaja de forma muy  activa [[Pal]] et al., [[2000]]; [[Cukier]] et al., [[1998]];  [[Schmitdt]] et al., 1998; [[Zinky]] et al., [[1997]].
 == Fuente ==

@@ Línea 43: / Línea 43: @@
 Otro tema, muy  relacionado con este, es  el de la [[Calidad de Servicio]] (QoS). En su  normativa, ISO define la [[QoS]] como “un conjunto de calidades  relacionadas con el comportamiento colectivo de uno o más objetos”. En  este sentido es importante señalar que fundamentalmente este tipo de  atributos van  a coincidir con los atributos de calidad que  pueden ser  medidos durante la ejecución del sistema o de los componentes. Sin  embargo, suelen ser más al nivel de sistema que de componentes, pues la  QoS se mide con respecto al comportamiento global del sistema y a los  resultados que éste produce.
-Por tanto, no es  suficiente con disponer de los valores de los atributos de calidad de  los componentes de un sistema, sino también influye la forma en la que  están conectados, el medio de transporte que utilizan para  comunicarse,  la complejidad de los protocolos de interacción entre ellos, etc. En  general este es un tema complejo y en el cual se trabaja de forma muy  activa [[[Pal]] et al., [[2000]]; [[Cukier]] et al., [[1998]];  [[Schmitdt]] et al., 1998; [[Zinky]] et al., 1997].
+Por tanto, no es  suficiente con disponer de los valores de los atributos de calidad de  los componentes de un sistema, sino también influye la forma en la que  están conectados, el medio de transporte que utilizan para  comunicarse,  la complejidad de los protocolos de interacción entre ellos, etc. En  general este es un tema complejo y en el cual se trabaja de forma muy  activa [[Pal]] et al., [[2000]]; [[Cukier]] et al., [[1998]];  [[Schmitdt]] et al., 1998; [[Zinky]] et al., 1997].
-== Fuente. ==
+== Fuente ==
-*  Bertoa, Manuel F., Troya, José M. y Vallecillo,Antonio. Aspectos de  Calidad en el Desarrollo de Software Basado en Componentes. Universidad  de Málaga.
+*  Bertoa, Manuel F., Troya, José M. y Vallecillo, Antonio. Aspectos de  Calidad en el Desarrollo de Software Basado en Componentes. Universidad  de [[Málaga]].
 [[Category: Ingeniería_de_software]]

Calidad en el Desarrollo Software Basado en Componentes - Historial de revisiones

Josefina: Texto reemplazado: «» por «»

Eralarcon jc.bayamo1 en 22:29 13 sep 2013

Leydis jc.manzanillo4 en 22:01 6 oct 2011

Leydis jc.manzanillo4 en 21:50 6 oct 2011

Diamela jc.bayamo8 en 17:00 6 oct 2011

Diamela jc.bayamo8: /* Fuente. */

Eralarcon jc.bayamo1: /* Otras características. */

Eralarcon jc.bayamo1 en 18:09 3 oct 2011

Eralarcon jc.bayamo1: /* Fuente. */

Eralarcon jc.bayamo1: /* Otras características. */

Josefina: Texto reemplazado: «
» por «»