Calidad de Software - Material de Estudio

CALIDAD DE SOFTWARE

MATERIAL MATERIAL MATERIAL MATERIAL

ING. FELIPE ALIAGA CAVEROING. FELIPE ALIAGA CAVEROING. FELIPE ALIAGA CAVEROING. FELIPE ALIAGA CAVERO

CALIDAD DE SOFTWARE

MATERIAL MATERIAL MATERIAL MATERIAL DE ESTUDIODE ESTUDIODE ESTUDIODE ESTUDIO


2010-II

CALIDAD DE SOFTWARE

DE ESTUDIODE ESTUDIODE ESTUDIODE ESTUDIO


ING. FELIPE OMAR ALIAGA CAVERO

UNIDAD DIDÁCTICA N°

FUNDAMENTOS DE


MODELOS Y ESTÁNDARES


MÉTRICAS


EJECUCIÓN DEL

CALIDAD DE SOFTWARE

CONTENIDO

UNIDAD DIDÁCTICA N° 01:

FUNDAMENTOS DE LA CALIDAD DEL SOFTWARE


Y ESTÁNDARES DE CALIDAD DE SOFTWARE


MÉTRICAS DE CALIDAD DEL SOFTWARE


EJECUCIÓN DEL CONTROL DE CALIDAD DE SOFTWARE

CALIDAD DE SOFTWARE

2

LA CALIDAD DEL SOFTWARE

DE CALIDAD DE SOFTWARE

CONTROL DE CALIDAD DE SOFTWARE



FUNDAMENTOS

FUNDAMENTOS DE CALIDAD Introducción

La calidad es el factor básico de decisión del cliente para un número de productos y servicios que hoy crece en forma explosiva. La calidad ha llegado a ser la fuerza más importante y única que lleva al éxito organizacional y al crecimiento de la compañía en mercados nacionales e internacionales. Los rendimientos de programas de calidad fuerte y eficiente están generando excelentes resultados de utilidades en empresas con estrategias de calidad eficientes. Esto está demostrado por los importantes aumentos en la penetración del mercado, por mejoras importantes en la productividad total, por los costos muchos menores de calidad y por un liderazgo competitivo más fuerte. Cuando se menciona el término"calidad", por lo general lo asociamos con productos o servicios excelentes, que satisfacen nuestras expectativas y, más aún, las rebasan. Tales expectativas se definen en función del uso que se le dará al producto o servicio en cuestión y de su respectivCuando un producto mejora nuestras expectativas estamos hablando de calidad. Es decir, se trata de una cualidad cuya valoración dependerá de lo que se perciba. De acuerdo a la norma A3 características de un producto o servicio que permiten satisfacer necesidades implícita o explícitamente formuladas. Estas últimas se definen mediante un contrato, en tanto que las primeras se definen según las condiciones que imperen en el mercado,también determinarlas y definirlas. Debido a la gran variación de resultados de calidad, la búsqueda genuina del éxito en la calidad se ha convertido en un asunto de gran interés en la administración de las compañías de todo el mundo. Y la experiencia está abriendo una base fundamental para lograr ese éxito. La calidad es en esencia una forma de administrar a la organización. Como finanzas y mercadotecnia, la calidad ha llegado a ser ahora un elemento esencial de la administración moderna. Y la eficiencia en la administración de la calidad se ha convertido en una condición necesaria para la eficiencia de la administración industrial en sí.

Origen de la Calidad

Como nos tienen acostumbrados, los japoneses fueron los pioneros. La II Gula economía nipona en una situación catastrófica, con unos productos poco competitivos que no tenían cabida en los mercados internacionales.se lanzaron al mercado gracias a la adopción de los sistque Japón registró un espectacular crecimiento.otras zonas del planeta. Europa tardó algo más, pero también fueron los años 80 los del impulso definitivo. En 1988 nace la Eorganización que apuesta por los modelos de gestión de calidad total (GTC o TQM), estrategias encaminadas a optimizar los recursos, reducir costes y mejorar los resultados, con el objetivo de perfeccionar cocalidad total es un proceso largo y complicado, supone cambiar la filosofía de la empresa y los modos de gestión de sus responsables; se debe elegir un problema concreto, y analizar el punto en donde esté fallando la empresa.

CALIDAD DE SOFTWARE

UNIDAD DIDÁCTICA N° 01

FUNDAMENTOS DE LA CALIDAD DE SOFTWARE

FUNDAMENTOS DE CALIDAD

La calidad es el factor básico de decisión del cliente para un número de productos y servicios que hoy crece en forma explosiva. La calidad ha llegado a ser la fuerza más importante y

lleva al éxito organizacional y al crecimiento de la compañía en mercados nacionales e internacionales. Los rendimientos de programas de calidad fuerte y eficiente están generando excelentes resultados de utilidades en empresas con estrategias de calidad

ficientes. Esto está demostrado por los importantes aumentos en la penetración del mercado, por mejoras importantes en la productividad total, por los costos muchos menores de calidad y por un liderazgo competitivo más fuerte. Cuando se menciona el término"calidad", por lo general lo asociamos con productos o servicios excelentes, que satisfacen nuestras expectativas y, más aún, las rebasan. Tales expectativas se definen en función del uso que se le dará al producto o servicio en cuestión y de su respectivCuando un producto mejora nuestras expectativas estamos hablando de calidad. Es decir, se trata de una cualidad cuya valoración dependerá de lo que se perciba.

De acuerdo a la norma A3 – 1987 ANSI / ASQC, Calidad es la totalidad de aspecaracterísticas de un producto o servicio que permiten satisfacer necesidades implícita o explícitamente formuladas. Estas últimas se definen mediante un contrato, en tanto que las primeras se definen según las condiciones que imperen en el mercado, también determinarlas y definirlas.

Debido a la gran variación de resultados de calidad, la búsqueda genuina del éxito en la calidad se ha convertido en un asunto de gran interés en la administración de las compañías

. Y la experiencia está abriendo una base fundamental para lograr ese éxito. La calidad es en esencia una forma de administrar a la organización. Como finanzas y mercadotecnia, la calidad ha llegado a ser ahora un elemento esencial de la administración

erna. Y la eficiencia en la administración de la calidad se ha convertido en una condición necesaria para la eficiencia de la administración industrial en sí.

Como nos tienen acostumbrados, los japoneses fueron los pioneros. La II Gula economía nipona en una situación catastrófica, con unos productos poco competitivos que no tenían cabida en los mercados internacionales. Los japoneses no tardaron en reaccionar: se lanzaron al mercado gracias a la adopción de los sistemas de calidad. Los resultados fueron que Japón registró un espectacular crecimiento. La iniciativa nipona pronto se transmitió a otras zonas del planeta. Europa tardó algo más, pero también fueron los años 80 los del

En 1988 nace la European Foundation for Quality Managment (EFQM), organización que apuesta por los modelos de gestión de calidad total (GTC o TQM), estrategias encaminadas a optimizar los recursos, reducir costes y mejorar los resultados, con el objetivo de perfeccionar constantemente el proceso productivo. La implantación de la calidad total es un proceso largo y complicado, supone cambiar la filosofía de la empresa y los modos de gestión de sus responsables; se debe elegir un problema concreto, y analizar el

e esté fallando la empresa.

CALIDAD DE SOFTWARE

3

CALIDAD DE SOFTWARE

La calidad es el factor básico de decisión del cliente para un número de productos y servicios que hoy crece en forma explosiva. La calidad ha llegado a ser la fuerza más importante y

lleva al éxito organizacional y al crecimiento de la compañía en mercados nacionales e internacionales. Los rendimientos de programas de calidad fuerte y eficiente están generando excelentes resultados de utilidades en empresas con estrategias de calidad

ficientes. Esto está demostrado por los importantes aumentos en la penetración del mercado, por mejoras importantes en la productividad total, por los costos muchos menores de calidad y por un liderazgo competitivo más fuerte. Cuando se menciona el término "calidad", por lo general lo asociamos con productos o servicios excelentes, que satisfacen nuestras expectativas y, más aún, las rebasan. Tales expectativas se definen en función del uso que se le dará al producto o servicio en cuestión y de su respectivo precio de venta. Cuando un producto mejora nuestras expectativas estamos hablando de calidad. Es decir, se

1987 ANSI / ASQC, Calidad es la totalidad de aspectos y características de un producto o servicio que permiten satisfacer necesidades implícita o explícitamente formuladas. Estas últimas se definen mediante un contrato, en tanto que las

aunque es necesario

Debido a la gran variación de resultados de calidad, la búsqueda genuina del éxito en la calidad se ha convertido en un asunto de gran interés en la administración de las compañías

. Y la experiencia está abriendo una base fundamental para lograr ese éxito. La calidad es en esencia una forma de administrar a la organización. Como finanzas y mercadotecnia, la calidad ha llegado a ser ahora un elemento esencial de la administración

erna. Y la eficiencia en la administración de la calidad se ha convertido en una condición

Como nos tienen acostumbrados, los japoneses fueron los pioneros. La II Guerra Mundial dejó la economía nipona en una situación catastrófica, con unos productos poco competitivos que

Los japoneses no tardaron en reaccionar: emas de calidad. Los resultados fueron

La iniciativa nipona pronto se transmitió a otras zonas del planeta. Europa tardó algo más, pero también fueron los años 80 los del

uropean Foundation for Quality Managment (EFQM), organización que apuesta por los modelos de gestión de calidad total (GTC o TQM), estrategias encaminadas a optimizar los recursos, reducir costes y mejorar los resultados, con

La implantación de la calidad total es un proceso largo y complicado, supone cambiar la filosofía de la empresa y los modos de gestión de sus responsables; se debe elegir un problema concreto, y analizar el


Los principios de gestión de la calidad total son sencillos de entender, pero complicados de asimilar:

• El sistema parte de la búsqueda de la satisfacción del cliente, en todos sus aspectos. • Un primer paso es la búsqueda de la c• Pero habrá que tener en claro que el producto/servicio ya no será el punto principal

de calidad. Los principios elementales son los siguientes:

• De poco sirve imponer de forma autoritaria la mejora en cada puesto de tra• La calidad la produce el último eslabón que termina el producto ó que está en

contacto con el cliente pero nunca el director general. • El directivo tiene que estar convencido de la necesidad de la calidad.

Concepto de Calidad

Es cuando en una organización se determinan las actividades y los integrantes de la misma se encuentran haciendo lo que tienen que hacer, lo están haciendo bien, para brindarle una satisfacción total al cliente. Análisis del concepto “haciendo lo que tienen que hacer”, se

• Determinación de las actividades • Conocimiento de los requisitos a cumplir • Adiestramiento sobre esos requisitos (capacitación) • Cumplimiento estricto de esos requisitos

Si se conocen los requisitos no se necesita supervisión, ya que se sabe “lo están haciendo bien”Implica la predisposición o la integración de la organización (el compromiso). Es la diferencia entre tener y querer ir a trabajar, creando un mejor ambiente de trabajo. “brindar satisfacción total al cliente”Calidad Total es cuando en la organización, los integrantes se encuentran cumpliendo exactamente con todos los requisitos establecidos y normalizados hacia la del la búsqueda del Cero Defecto, para brindarle satisfacción total al cliente. Cliente es todo aquel que se ve afectado por lo que haga o deje de hacer. Es aquel que depende de mí, es decir, tiene una dependencia directa; aquel que me sigue en la línea (cliente interno) y todos aquellos que me dependen (razón trascendental).limita a una técnica administrativa o de gestión, sino que su concepción es mucho más profunda, ya que empieza y termina con las personas, es decir que es una filosofía que se demuestra en el ser, pensar y actuar de las personas de Calidad. Personas de Calidad obtienen productos de calidad y brindan servicios de calidad. Se ha definido al Mejoramiento del personal como una forma de lograr la calidad total, y como una conversión en el mecanismo viable y accesible al que las empresas de los países en vías de desarrollo cierren la brecha tecnológica que mantienen con respecto al mundo competitivo y desarrollado. Para mejorar un proceso y llegar a la calidad total, y ser en consecuencia más competitivos, es necesario cambiar dicho proceso, para hacerlo más efectivo, eficadaptable. Qué cambiar y cómo cambiar depende del enfoque específico del empresario y del proceso. LA CLAVE DEL ÉXITO ES LA CALIDAD TOTAL DE MANTENER SISTEMÁTICAMENTE VENTAJAS QUE LE PERMITAN ALCANZAR DETERMINADA POSICIÓN EN EL ENTORNO SOCIOECONÓM

CALIDAD DE SOFTWARE

Los principios de gestión de la calidad total son sencillos de entender, pero complicados de asimilar:

El sistema parte de la búsqueda de la satisfacción del cliente, en todos sus aspectos. Un primer paso es la búsqueda de la calidad de los productos/servicios. Pero habrá que tener en claro que el producto/servicio ya no será el punto principal

Los principios elementales son los siguientes: De poco sirve imponer de forma autoritaria la mejora en cada puesto de traLa calidad la produce el último eslabón que termina el producto ó que está en contacto con el cliente pero nunca el director general. El directivo tiene que estar convencido de la necesidad de la calidad.

organización se determinan las actividades y los integrantes de la misma se encuentran haciendo lo que tienen que hacer, lo están haciendo bien, para brindarle una satisfacción total al cliente.

“haciendo lo que tienen que hacer”, se refiere a:

Determinación de las actividades Conocimiento de los requisitos a cumplir Adiestramiento sobre esos requisitos (capacitación) Cumplimiento estricto de esos requisitos

Si se conocen los requisitos no se necesita supervisión, ya que se sabe qué hacer.

“lo están haciendo bien” Implica la predisposición o la integración de la organización (el compromiso). Es la diferencia entre tener y querer ir a trabajar, creando un mejor ambiente de trabajo.

“brindar satisfacción total al cliente” Total es cuando en la organización, los integrantes se encuentran cumpliendo

exactamente con todos los requisitos establecidos y normalizados hacia la del la búsqueda del Cero Defecto, para brindarle satisfacción total al cliente.

que se ve afectado por lo que haga o deje de hacer. Es aquel que depende de mí, es decir, tiene una dependencia directa; aquel que me sigue en la línea (cliente interno) y todos aquellos que me dependen (razón trascendental).

na técnica administrativa o de gestión, sino que su concepción es mucho más profunda, ya que empieza y termina con las personas, es decir que es una filosofía que se demuestra en el ser, pensar y actuar de las personas de Calidad. Personas de Calidad

nen productos de calidad y brindan servicios de calidad.

Se ha definido al Mejoramiento del personal como una forma de lograr la calidad total, y como una conversión en el mecanismo viable y accesible al que las empresas de los países en vías

o cierren la brecha tecnológica que mantienen con respecto al mundo competitivo Para mejorar un proceso y llegar a la calidad total, y ser en consecuencia más

competitivos, es necesario cambiar dicho proceso, para hacerlo más efectivo, eficadaptable. Qué cambiar y cómo cambiar depende del enfoque específico del empresario y del

LA CLAVE DEL ÉXITO ES LA CALIDAD TOTAL DE MANTENER SISTEMÁTICAMENTE VENTAJAS QUE LE PERMITAN ALCANZAR DETERMINADA POSICIÓN EN EL ENTORNO SOCIOECONÓMICO.

CALIDAD DE SOFTWARE

4

Los principios de gestión de la calidad total son sencillos de entender, pero

El sistema parte de la búsqueda de la satisfacción del cliente, en todos sus aspectos. alidad de los productos/servicios.

Pero habrá que tener en claro que el producto/servicio ya no será el punto principal

De poco sirve imponer de forma autoritaria la mejora en cada puesto de trabajo. La calidad la produce el último eslabón que termina el producto ó que está en

El directivo tiene que estar convencido de la necesidad de la calidad.

organización se determinan las actividades y los integrantes de la misma se encuentran haciendo lo que tienen que hacer, lo están haciendo bien, para brindarle una

qué hacer.

Implica la predisposición o la integración de la organización (el compromiso). Es la diferencia entre tener y querer ir a trabajar, creando un mejor ambiente de trabajo.

Total es cuando en la organización, los integrantes se encuentran cumpliendo exactamente con todos los requisitos establecidos y normalizados hacia la del la búsqueda del

que se ve afectado por lo que haga o deje de hacer. Es aquel que depende de mí, es decir, tiene una dependencia directa; aquel que me sigue en la línea (cliente interno) y todos aquellos que me dependen (razón trascendental). Calidad Total no se

na técnica administrativa o de gestión, sino que su concepción es mucho más profunda, ya que empieza y termina con las personas, es decir que es una filosofía que se demuestra en el ser, pensar y actuar de las personas de Calidad. Personas de Calidad

Se ha definido al Mejoramiento del personal como una forma de lograr la calidad total, y como una conversión en el mecanismo viable y accesible al que las empresas de los países en vías

o cierren la brecha tecnológica que mantienen con respecto al mundo competitivo Para mejorar un proceso y llegar a la calidad total, y ser en consecuencia más

competitivos, es necesario cambiar dicho proceso, para hacerlo más efectivo, eficiente y adaptable. Qué cambiar y cómo cambiar depende del enfoque específico del empresario y del

LA CLAVE DEL ÉXITO ES LA CALIDAD TOTAL DE MANTENER SISTEMÁTICAMENTE VENTAJAS QUE LE PERMITAN ALCANZAR DETERMINADA POSICIÓN EN EL


El término calidad total es muy utilizado en los medios empresariales, políticos y socioeconómicos en general. A ello se debe la ampliación del marco de referencia de nuestros agentes económicos que han pasado de una actitud auto protectora a un plantabierto, expansivo y proactivo. La ventaja comparativaatributos, etc., de los que dispone dicha empresa, los mismos de los que carecen sus competidores o que estos tienen en mrendimientos superiores a los de aquellos.orientación hacia el entorno y una actitud estratégica por parte de las empresas grandes como en las pequeñas, en clase de organización. Por otra parte, el concepto de éxito nos hace pensar en la idea "excelencia", o sea, con características de eficiencia y eficacia de la organización. El Concepto de Calidad Total tiene Cuatro Etapas:

1) Hacer de la calidad un socio pleno e igual de la innovación, desde el comienzo del desarrollo del producto.

2) Poner énfasis en que el diseño de un producto de alta calidad y el proceso coincidan en forma ascendentecongelado ya las alternativas.

3) Hacer de todos los servicios de los proveedores un socio de calidad al comenzar el diseño; en lugar de un problema de vigilancia de la calidad, más adelante.

4) Hacer de la aceleracuna medida primaria de la eficacia del programa de calidad de una compañía. El cuarto punto fundamental es que la calidad y el costo son complementarios y no objetivos conflictos del negocio.

Estos fundamentos aclaran que el liderazgo de la calidad es hoy en día la clave del éxito del negocio de las compañías y que ello se suma a las economías nacionales. En correspondencia, las iniciativas nacionales y regionales están resultando de importanciadel liderazgo de la calidad.

¿Qué es Calidad Total? La calidad total es un concepto, una filosofía, una estrategia, un modelo de hacer negocios y está localizado hacia el cliente. La calidad total no solo se refiere al producto osino que es la mejoría permanente del aspecto organizacional, gerencial; tomando una empresa como una máquina gigantesca, donde cada trabajador, desde el gerente, hasta el funcionario del más bajo nivel jerárquico está comprometido con losPara que la calidad total se logre a plenitud, es necesario que se rescaten los valores morales básicos de la sociedad y es aquí, donde el empresario juega un papel fundamental, empezando por la educación previa de sus trabajadoremás predispuesta, con mejor capacidad de asimilar los problemas de calidad, con mejor criterio para sugerir cambios en provecho de la calidad, con mejor capacidad de análisis y observación del proceso de manufactura euso de la calidad total conlleva ventajas, pudiendo citar como ejemplos las siguientes:

• Potencialmente alcanzable si hay decisión del más alto nivel. • Mejora la relación del recurso humano con la dirección. • Reduce los costos aumentando la productividad.

Principios de la Calidad

1. Cumplir con los requisitos. Para ello los directivos deben:

• Establecer los requisitos a cumplir

CALIDAD DE SOFTWARE

El término calidad total es muy utilizado en los medios empresariales, políticos y socioeconómicos en general. A ello se debe la ampliación del marco de referencia de nuestros agentes económicos que han pasado de una actitud auto protectora a un plantabierto, expansivo y proactivo.

La ventaja comparativa de una empresa estaría en su habilidad, recursos, conocimientos y atributos, etc., de los que dispone dicha empresa, los mismos de los que carecen sus competidores o que estos tienen en menor medida, que hace posible la obtención de unos rendimientos superiores a los de aquellos. El uso de estos conceptos supone una continua orientación hacia el entorno y una actitud estratégica por parte de las empresas grandes como en las pequeñas, en las de reciente creación o en las maduras y en general en cualquier clase de organización. Por otra parte, el concepto de éxito nos hace pensar en la idea "excelencia", o sea, con características de eficiencia y eficacia de la organización.

Calidad Total tiene Cuatro Etapas:

acer de la calidad un socio pleno e igual de la innovación, desde el comienzo del desarrollo del producto. Poner énfasis en que el diseño de un producto de alta calidad y el proceso coincidan

ascendente, no después que la planeación de la manufactura haya congelado ya las alternativas.

acer de todos los servicios de los proveedores un socio de calidad al comenzar el diseño; en lugar de un problema de vigilancia de la calidad, más adelante.

acer de la aceleración de la introducción de un nuevo producto una medida primaria de la eficacia del programa de calidad de una compañía. El cuarto punto fundamental es que la calidad y el costo son complementarios y no objetivos conflictos del negocio.

stos fundamentos aclaran que el liderazgo de la calidad es hoy en día la clave del éxito del negocio de las compañías y que ello se suma a las economías nacionales. En correspondencia, las iniciativas nacionales y regionales están resultando de importancia creciente en el fomento del liderazgo de la calidad.

La calidad total es un concepto, una filosofía, una estrategia, un modelo de hacer negocios y está localizado hacia el cliente. La calidad total no solo se refiere al producto osino que es la mejoría permanente del aspecto organizacional, gerencial; tomando una empresa como una máquina gigantesca, donde cada trabajador, desde el gerente, hasta el funcionario del más bajo nivel jerárquico está comprometido con los objetivos empresariales. Para que la calidad total se logre a plenitud, es necesario que se rescaten los valores morales básicos de la sociedad y es aquí, donde el empresario juega un papel fundamental, empezando por la educación previa de sus trabajadores para conseguir una población laboral más predispuesta, con mejor capacidad de asimilar los problemas de calidad, con mejor criterio para sugerir cambios en provecho de la calidad, con mejor capacidad de análisis y observación del proceso de manufactura en caso de productos y poder enmendar errores.uso de la calidad total conlleva ventajas, pudiendo citar como ejemplos las siguientes:

Potencialmente alcanzable si hay decisión del más alto nivel. Mejora la relación del recurso humano con la dirección. Reduce los costos aumentando la productividad.

Cumplir con los requisitos. Para ello los directivos deben: Establecer los requisitos a cumplir

CALIDAD DE SOFTWARE

5

El término calidad total es muy utilizado en los medios empresariales, políticos y socioeconómicos en general. A ello se debe la ampliación del marco de referencia de nuestros agentes económicos que han pasado de una actitud auto protectora a un planteamiento más

de una empresa estaría en su habilidad, recursos, conocimientos y atributos, etc., de los que dispone dicha empresa, los mismos de los que carecen sus

enor medida, que hace posible la obtención de unos El uso de estos conceptos supone una continua

orientación hacia el entorno y una actitud estratégica por parte de las empresas grandes las de reciente creación o en las maduras y en general en cualquier

clase de organización. Por otra parte, el concepto de éxito nos hace pensar en la idea "excelencia", o sea, con características de eficiencia y eficacia de la organización.

acer de la calidad un socio pleno e igual de la innovación, desde el comienzo del

Poner énfasis en que el diseño de un producto de alta calidad y el proceso coincidan spués que la planeación de la manufactura haya

acer de todos los servicios de los proveedores un socio de calidad al comenzar el diseño; en lugar de un problema de vigilancia de la calidad, más adelante.

ión de la introducción de un nuevo producto – no su retardo – una medida primaria de la eficacia del programa de calidad de una compañía. El cuarto punto fundamental es que la calidad y el costo son complementarios y no

stos fundamentos aclaran que el liderazgo de la calidad es hoy en día la clave del éxito del negocio de las compañías y que ello se suma a las economías nacionales. En correspondencia,

creciente en el fomento

La calidad total es un concepto, una filosofía, una estrategia, un modelo de hacer negocios y está localizado hacia el cliente. La calidad total no solo se refiere al producto o servicio en sí, sino que es la mejoría permanente del aspecto organizacional, gerencial; tomando una empresa como una máquina gigantesca, donde cada trabajador, desde el gerente, hasta el

objetivos empresariales. Para que la calidad total se logre a plenitud, es necesario que se rescaten los valores morales básicos de la sociedad y es aquí, donde el empresario juega un papel fundamental,

s para conseguir una población laboral más predispuesta, con mejor capacidad de asimilar los problemas de calidad, con mejor criterio para sugerir cambios en provecho de la calidad, con mejor capacidad de análisis y

n caso de productos y poder enmendar errores. El uso de la calidad total conlleva ventajas, pudiendo citar como ejemplos las siguientes:


• Suministrar los medios nece• Motivar y estimular para que los requisitos sean cumplidos

2. La Calidad es la Prevención, no la verificación3. El estándar de realización es el Cero Defectos4. La medida de la Calidad es el precio por el incumplimiento

Factores esenciales para introducir el Control Total de Calidad

• Conciencia: en todos los niveles de la organización• Trabajo en equipo: es el pilar de la Calidad, trabajar en mutua cooperación y sin

autoritarismo. • Control y mejoramiento: mejorar sobre lo

que se puede medir. Planes de mejora.• Sistematización: en busca de la perfección de las actividades de la organización.• Conocimiento y comparación de costos• Evaluación: debe ser constante y retroalimentadora, a la ve

sobre los esfuerzos de los trabajadores en la actividad.• Difusión: se debe comunicar qué se hace y qué pasa en la organización en todos los

niveles. La calidad total en la organización de una empresa, debe ser el nervio y motor dde verdad la empresa desea alcanzar el éxito debe cimentarse en estas dos palabras.mensaje de la calidad total debe ser comunicado a tres audiencias que son complementarias entre sí:

• Los Trabajadores. • Los Proveedores; y, • Los Clientes.

Los fundamentos de la calidad total son los siguientes:

• El objetivo básico: la competitividad • El trabajo bien hecho. • La Mejora continuada con la colaboración de todos: responsabilidad y compromiso

individual por la calidad. • El trabajo en equipo es fun• Comunicación, información, participación y reconocimiento. • Prevención del error y eliminación temprana del defecto. • Fijación de objetivos de mejora. • Seguimiento de resultados. • Indicadores de gestión. • Satisfacer las necesidades del cliente: calidad, precio, plazo.

Los obstáculos que impiden el avance de la calidad pueden ser:

• El hecho de que la dirección no defina lo que entiende por calidad. • No se trata de hacer bien las cosas, sino de que el client

satisfecho. • Todos creen en su concepto, pocos en su importancia y son menos los que la

practican. El Control de la Calidad

Se posesiona como una estrategia para asegurar el mejoramiento continuo de la calidad. Es un programa para asegurar la contimediante el desarrollo permanente de la calidad del producto y sus servicios.que involucra la orientación de la organización a la calidad manifestada en sus productos, servicios, desarrollo de su personal y contribución al bienestar general.continuo es una herramienta que en la actualidad es fundamental para todas las empresas porque les permite renovar los procesos administrativos que ellos realizan, lo cu

CALIDAD DE SOFTWARE

Suministrar los medios necesarios para que los empleados cumplan Motivar y estimular para que los requisitos sean cumplidos

La Calidad es la Prevención, no la verificación El estándar de realización es el Cero Defectos La medida de la Calidad es el precio por el incumplimiento

ctores esenciales para introducir el Control Total de Calidad Conciencia: en todos los niveles de la organización Trabajo en equipo: es el pilar de la Calidad, trabajar en mutua cooperación y sin

Control y mejoramiento: mejorar sobre lo medido, ya que solo se puede mejorar lo que se puede medir. Planes de mejora. Sistematización: en busca de la perfección de las actividades de la organización.Conocimiento y comparación de costos Evaluación: debe ser constante y retroalimentadora, a la vez que debe ser imparcial sobre los esfuerzos de los trabajadores en la actividad. Difusión: se debe comunicar qué se hace y qué pasa en la organización en todos los

La calidad total en la organización de una empresa, debe ser el nervio y motor dde verdad la empresa desea alcanzar el éxito debe cimentarse en estas dos palabras.mensaje de la calidad total debe ser comunicado a tres audiencias que son complementarias

Los Trabajadores. Los Proveedores; y,

Los fundamentos de la calidad total son los siguientes: El objetivo básico: la competitividad El trabajo bien hecho. La Mejora continuada con la colaboración de todos: responsabilidad y compromiso individual por la calidad. El trabajo en equipo es fundamental para la mejora permanente Comunicación, información, participación y reconocimiento. Prevención del error y eliminación temprana del defecto. Fijación de objetivos de mejora. Seguimiento de resultados. Indicadores de gestión. Satisfacer las necesidades del cliente: calidad, precio, plazo.

Los obstáculos que impiden el avance de la calidad pueden ser: El hecho de que la dirección no defina lo que entiende por calidad. No se trata de hacer bien las cosas, sino de que el cliente opine igual y esté

Todos creen en su concepto, pocos en su importancia y son menos los que la

e posesiona como una estrategia para asegurar el mejoramiento continuo de la calidad. Es segurar la continua satisfacción de los clientes externos e internos

mediante el desarrollo permanente de la calidad del producto y sus servicios.que involucra la orientación de la organización a la calidad manifestada en sus productos,

vicios, desarrollo de su personal y contribución al bienestar general.continuo es una herramienta que en la actualidad es fundamental para todas las empresas porque les permite renovar los procesos administrativos que ellos realizan, lo cu

CALIDAD DE SOFTWARE

6

sarios para que los empleados cumplan

Trabajo en equipo: es el pilar de la Calidad, trabajar en mutua cooperación y sin

medido, ya que solo se puede mejorar lo

Sistematización: en busca de la perfección de las actividades de la organización.

z que debe ser imparcial

Difusión: se debe comunicar qué se hace y qué pasa en la organización en todos los

La calidad total en la organización de una empresa, debe ser el nervio y motor de la misma; si de verdad la empresa desea alcanzar el éxito debe cimentarse en estas dos palabras. El mensaje de la calidad total debe ser comunicado a tres audiencias que son complementarias

La Mejora continuada con la colaboración de todos: responsabilidad y compromiso

El hecho de que la dirección no defina lo que entiende por calidad. e opine igual y esté

Todos creen en su concepto, pocos en su importancia y son menos los que la

e posesiona como una estrategia para asegurar el mejoramiento continuo de la calidad. Es satisfacción de los clientes externos e internos

mediante el desarrollo permanente de la calidad del producto y sus servicios. Es un concepto que involucra la orientación de la organización a la calidad manifestada en sus productos,

vicios, desarrollo de su personal y contribución al bienestar general. El mejoramiento continuo es una herramienta que en la actualidad es fundamental para todas las empresas porque les permite renovar los procesos administrativos que ellos realizan, lo cual hace que


las empresas estén en constante actualización; además, permite que las organizaciones sean más eficientes y competitivas, fortalezas que le ayudarán a permanecer en el mercado.la aplicación del mejoramiento es necesario que en la comunicación entre todos los órganos que la conforman, y también los empleados deben estar bien compenetrados con la organización, porque ellos pueden ofrecer mucha información valiosa para llevar a cabo de forma óptima el proLa definición de una estrategia asegura que la organización está haciendo las cosas que debe hacer para lograr sus objetivos. La definición de su sistema determina si está haciendo estas cosas correctamente. La calidad de losa lograr la satisfacción de sus clientes (internos o externos). Es el proceso de alcanzar los objetivos de calidad durante las operaciones. Para el efecto, se deberán desarrollar los siguientes pasos:

a) Elegir qué controlar. b) Determinar las unidades de medición. c) Establecer el sistema de medición. d) Establecer los estándares de desempeño. e) Medir el desempeño actual. f) Interpretar la diferencia entre lo real y el estándar. g) Tomar acción sobre la diferencia.

El término calidad se ha convertido en una de las palabras clave de nuestra sociedad, alcanzando tal grado de relevancia que iguala e incluso supera en ocasiones al factor precio, en cuanto a la importancia otorgada por Las necesidades de quienes compran nuestros productos o servicios no son estáticas, sino que evolucionan de forma continua.procesos productivos y comercSU FIDELIDAD.

Pasos para poner en marcha el Control de Calidad

Cada uno de los conceptos de la estrategia del Control Total de Calidad conlleva muchas actividades. Por lo tanto se hace necesariasegure el éxito de su aplicación en la empresa. Un plan para poner en práctica el Control Total de Calidad, podría contener las siguientes actividades: COMPROMISO Y ORGANIZACIÓN.

1. Establecimiento del compcon las actividades de los círculos de control de calidad. Debe establecerse el por que de esta decisión. Para ello es básico conocer los conceptos básicos de CTC, sus beneficios, la importancia doptimizar recursos y tecnología, lo vital del ciclo de control y aspectos similares.

2. Organización de un comité directivo o de un consejo.3. Designación de los miembros del comité de CTC.4. Organización de una oficina de CTC para los miembros del comité o consejo, así como

para la promoción CTC.5. Designación del director de la oficina de CTC así como de los facilitadores de CTC.

Estos últimos son el apoyo metodológico para la implantación del CTC en toda laorganización.

PLANEACIÓN

1. Establecimiento de la política de implementación del CTC y del programa para lograrlo. Esto debe hacerlo el comité o el consejo.

CALIDAD DE SOFTWARE

las empresas estén en constante actualización; además, permite que las organizaciones sean más eficientes y competitivas, fortalezas que le ayudarán a permanecer en el mercado.la aplicación del mejoramiento es necesario que en la organización exista una buena comunicación entre todos los órganos que la conforman, y también los empleados deben estar bien compenetrados con la organización, porque ellos pueden ofrecer mucha información valiosa para llevar a cabo de forma óptima el proceso de mejoramiento continuo. La definición de una estrategia asegura que la organización está haciendo las cosas que debe hacer para lograr sus objetivos. La definición de su sistema determina si está haciendo estas cosas correctamente. La calidad de los procesos se mide por el grado de adecuación de estos a lograr la satisfacción de sus clientes (internos o externos).

Es el proceso de alcanzar los objetivos de calidad durante las operaciones. Para el efecto, se deberán desarrollar los siguientes pasos:

Elegir qué controlar. Determinar las unidades de medición. Establecer el sistema de medición. Establecer los estándares de desempeño. Medir el desempeño actual. Interpretar la diferencia entre lo real y el estándar. Tomar acción sobre la diferencia.

El término calidad se ha convertido en una de las palabras clave de nuestra sociedad, alcanzando tal grado de relevancia que iguala e incluso supera en ocasiones al factor precio, en cuanto a la importancia otorgada por el posible comprador de un producto o servicio.Las necesidades de quienes compran nuestros productos o servicios no son estáticas, sino que evolucionan de forma continua. Esto supone la permanente adaptación de todos nuestros procesos productivos y comerciales a dichas necesidades, si queremos seguir contando con

Pasos para poner en marcha el Control de Calidad

Cada uno de los conceptos de la estrategia del Control Total de Calidad conlleva muchas actividades. Por lo tanto se hace necesario establecer un plano o programa cuyo desarrollo asegure el éxito de su aplicación en la empresa. Un plan para poner en práctica el Control Total de Calidad, podría contener las siguientes actividades:

COMPROMISO Y ORGANIZACIÓN.

Establecimiento del compromiso de la alta dirección con la implementación del CTC y con las actividades de los círculos de control de calidad. Debe establecerse el por que de esta decisión. Para ello es básico conocer los conceptos básicos de CTC, sus beneficios, la importancia del cliente, el valor del recurso humano, la necesidad de optimizar recursos y tecnología, lo vital del ciclo de control y aspectos similares.Organización de un comité directivo o de un consejo. Designación de los miembros del comité de CTC.

e una oficina de CTC para los miembros del comité o consejo, así como para la promoción CTC. Designación del director de la oficina de CTC así como de los facilitadores de CTC. Estos últimos son el apoyo metodológico para la implantación del CTC en toda la

Establecimiento de la política de implementación del CTC y del programa para lograrlo. Esto debe hacerlo el comité o el consejo.

CALIDAD DE SOFTWARE

7

las empresas estén en constante actualización; además, permite que las organizaciones sean más eficientes y competitivas, fortalezas que le ayudarán a permanecer en el mercado. Para

organización exista una buena comunicación entre todos los órganos que la conforman, y también los empleados deben estar bien compenetrados con la organización, porque ellos pueden ofrecer mucha

ceso de mejoramiento continuo. La definición de una estrategia asegura que la organización está haciendo las cosas que debe hacer para lograr sus objetivos. La definición de su sistema determina si está haciendo estas

procesos se mide por el grado de adecuación de estos

Es el proceso de alcanzar los objetivos de calidad durante las operaciones. Para el

El término calidad se ha convertido en una de las palabras clave de nuestra sociedad, alcanzando tal grado de relevancia que iguala e incluso supera en ocasiones al factor precio,

el posible comprador de un producto o servicio. Las necesidades de quienes compran nuestros productos o servicios no son estáticas, sino que

Esto supone la permanente adaptación de todos nuestros iales a dichas necesidades, si queremos seguir contando con

Cada uno de los conceptos de la estrategia del Control Total de Calidad conlleva muchas o establecer un plano o programa cuyo desarrollo

asegure el éxito de su aplicación en la empresa. Un plan para poner en práctica el Control

romiso de la alta dirección con la implementación del CTC y con las actividades de los círculos de control de calidad. Debe establecerse el por que de esta decisión. Para ello es básico conocer los conceptos básicos de CTC, sus

el cliente, el valor del recurso humano, la necesidad de optimizar recursos y tecnología, lo vital del ciclo de control y aspectos similares.

e una oficina de CTC para los miembros del comité o consejo, así como

Designación del director de la oficina de CTC así como de los facilitadores de CTC. Estos últimos son el apoyo metodológico para la implantación del CTC en toda la

Establecimiento de la política de implementación del CTC y del programa para


2. Visitas a otras empresas o países para visualizar la operación del CTC, por parte de la alta dirección, los gerentes, así como del director de la oficina de CTC y de los facilitadores.

3. Establecimiento de una plan adecuado a las condiciones de la empresa y de su correspondiente calendario de implementación; esta actividad es responsabilidad del director de la oficina de CTC.

EDUCACIÓN Y ENTRENAMIENTO

1. Realización de eventos de educación, dirigidos a la alta dirección.2. Realización de actividades educativas dirigidas a la gerencia, al director de la oficina

de CTC y a los facilitadores de CTC.3. Preparación del material educativo para la aplicación del CTC y de las 7 herramientas

básicas de control de calidad. El material deberá ser diseñado para directores, gerencia media, staff y supervisores.

4. Puesta en práctica del programa de educación y entrenamienprogramado. Esto incluye la aplicación de los conceptos aprendidos.

PRIMERAS ACCIONES

1. Una vez terminado el entrenamiento, "sacudida" de cada sección o departamento para identificar, con ayuda de los subordinados de cada sector, debilidades.

2. Diseño de un proyecto (uno fácil), como ejercicio de los casos de Ruta de Calidad (o de mejoramiento del control de calidad) y de la utilización efectiva de los datos: desarrollo de este con aplicación del ciclo de control (los calidad). Repetición de este ejercicio para el siguiente aspecto de menor dificultad. Cuando ya se esté familiarizado con el proceso, enfrentamiento con los proyectos críticos o importantes para el mejoramiento.

3. Realización de evenlos Círculos de Control de Calidad.

4. Promoción e instalación de Círculos de Control de Calidad piloto, voluntarios y con supervisión también voluntaria, para practicar de nuevo los ocho pasola Calidad. Repetición de estas actividades hasta terminar con lo estipulado en el plan y en el programa.

ADMINISTRACIÓN POR POLÍTICA Y ESTANDARIZACIÓN.

1. Preparación de un borrador de administración por políticas, por parte de la oficina dCTC.

2. Obtención de la aprobación por la alta dirección y el consejo de CTC.

Introducción

El desarrollo de sistemas hoy en día ha tomado gran importancia en el mundo, siendo ésta cada vez más creciente. Si una empresa de software pretende competir a nivel internacional, es necesario que contemple seriamente la CALIDAD DEL SOFTWARE Y DEL SISTEMA.que impiden que el sistema funcione como era de esperarse o que sea utilizado en su totalidad. Por ello, es necesario definir e impulsar líneas de acción tendientes sistema producido. Dentro de estas líneas de acción, está la relacionada con el proceso mismo del desarrollo del sistema, y como necesidad primordial, la de realizar una investigación que permita conocer de primera mano el estado en que se enc

CALIDAD DE SOFTWARE

Visitas a otras empresas o países para visualizar la operación del CTC, por parte de la dirección, los gerentes, así como del director de la oficina de CTC y de los

Establecimiento de una plan adecuado a las condiciones de la empresa y de su correspondiente calendario de implementación; esta actividad es responsabilidad del

ector de la oficina de CTC.

EDUCACIÓN Y ENTRENAMIENTO

Realización de eventos de educación, dirigidos a la alta dirección.Realización de actividades educativas dirigidas a la gerencia, al director de la oficina de CTC y a los facilitadores de CTC.

ación del material educativo para la aplicación del CTC y de las 7 herramientas básicas de control de calidad. El material deberá ser diseñado para directores, gerencia media, staff y supervisores. Puesta en práctica del programa de educación y entrenamiento a cada nivel, según lo programado. Esto incluye la aplicación de los conceptos aprendidos.

PRIMERAS ACCIONES

Una vez terminado el entrenamiento, "sacudida" de cada sección o departamento para identificar, con ayuda de los subordinados de cada sector,

Diseño de un proyecto (uno fácil), como ejercicio de los casos de Ruta de Calidad (o de mejoramiento del control de calidad) y de la utilización efectiva de los datos: desarrollo de este con aplicación del ciclo de control (los ocho pasos de la ruta de calidad). Repetición de este ejercicio para el siguiente aspecto de menor dificultad. Cuando ya se esté familiarizado con el proceso, enfrentamiento con los proyectos críticos o importantes para el mejoramiento. Realización de eventos educativos para los supervisores, en aspectos relacionados con los Círculos de Control de Calidad. Promoción e instalación de Círculos de Control de Calidad piloto, voluntarios y con supervisión también voluntaria, para practicar de nuevo los ocho pasola Calidad. Repetición de estas actividades hasta terminar con lo estipulado en el plan y en el programa.

ADMINISTRACIÓN POR POLÍTICA Y ESTANDARIZACIÓN.

Preparación de un borrador de administración por políticas, por parte de la oficina d

Obtención de la aprobación por la alta dirección y el consejo de CTC.

CALIDAD DE SOFTWARE

El desarrollo de sistemas hoy en día ha tomado gran importancia en el mundo, siendo ésta cada vez más creciente. Si una empresa de software pretende competir a nivel internacional, es necesario que contemple seriamente la necesidad de realizar una CERTIFICCALIDAD DEL SOFTWARE Y DEL SISTEMA. Muchos proyectos de sistemas presentan fallas que impiden que el sistema funcione como era de esperarse o que sea utilizado en su totalidad. Por ello, es necesario definir e impulsar líneas de acción tendientes

Dentro de estas líneas de acción, está la relacionada con el proceso mismo del desarrollo del sistema, y como necesidad primordial, la de realizar una investigación que permita conocer de primera mano el estado en que se encuentra su proceso de desarrollo.

CALIDAD DE SOFTWARE

8

Visitas a otras empresas o países para visualizar la operación del CTC, por parte de la dirección, los gerentes, así como del director de la oficina de CTC y de los

Establecimiento de una plan adecuado a las condiciones de la empresa y de su correspondiente calendario de implementación; esta actividad es responsabilidad del

Realización de eventos de educación, dirigidos a la alta dirección. Realización de actividades educativas dirigidas a la gerencia, al director de la oficina

ación del material educativo para la aplicación del CTC y de las 7 herramientas básicas de control de calidad. El material deberá ser diseñado para directores,

to a cada nivel, según lo programado. Esto incluye la aplicación de los conceptos aprendidos.

Una vez terminado el entrenamiento, "sacudida" de cada sección o departamento para identificar, con ayuda de los subordinados de cada sector, sus fuerzas y

Diseño de un proyecto (uno fácil), como ejercicio de los casos de Ruta de Calidad (o de mejoramiento del control de calidad) y de la utilización efectiva de los datos:

ocho pasos de la ruta de calidad). Repetición de este ejercicio para el siguiente aspecto de menor dificultad. Cuando ya se esté familiarizado con el proceso, enfrentamiento con los proyectos

tos educativos para los supervisores, en aspectos relacionados con

Promoción e instalación de Círculos de Control de Calidad piloto, voluntarios y con supervisión también voluntaria, para practicar de nuevo los ocho pasos de la Ruta de la Calidad. Repetición de estas actividades hasta terminar con lo estipulado en el plan

Preparación de un borrador de administración por políticas, por parte de la oficina de

Obtención de la aprobación por la alta dirección y el consejo de CTC.

El desarrollo de sistemas hoy en día ha tomado gran importancia en el mundo, siendo ésta cada vez más creciente. Si una empresa de software pretende competir a nivel internacional,

de realizar una CERTIFICACION DE Muchos proyectos de sistemas presentan fallas

que impiden que el sistema funcione como era de esperarse o que sea utilizado en su totalidad. Por ello, es necesario definir e impulsar líneas de acción tendientes a mejorar el

Dentro de estas líneas de acción, está la relacionada con el proceso mismo del desarrollo del sistema, y como necesidad primordial, la de realizar una investigación que

uentra su proceso de desarrollo.


Diferenciaremos dos conceptos importantes como son:

• El control de calidad de sistemas los sistemas en explotación.

• El control de calidad de software los programas que se están desarrollando.

La Ingeniería de Software concierne a teorías, métodos y herramientas para el desarrollo profesional de productos. Un Sistema concierne a un conjunto de componentes interrelacionados trabajando conjuntamente para un fin común. El sistema puede incluir software, dispositivos mecánicos y eléctricos, hardware, y ser operado por gente. Existen varias organizaciones de estandarización internacional que realizan estándares y modelos de ingeniería de software, esto con el fin de mejorar la Calidad del Software.

La Calidad

La ISO (International Standard Organization), define La Calidad como la ausencia de deficiencias: "Es la totalidad de aspectos y características de un producto o serviccapacidad para satisfacer necesidades dadas en la adecuación de sus objetivos'”.El Instituto de Ingeniería de Software (SEI) en su modelo CMM (Capability Maturity Model) define la calidad como:

• El grado en el cual un sistema, compespecificados.

• El grado en el cual el sistema, componente o proceso cumple con las expectativas del cliente o usuario.

• La calidad consiste en todos aquellos aspectos del producto que satisfacen las necesidades del cliente y de ese modo proporcionan la satisfacción del producto.

La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.cualidades que lo caracterizan y que determinan su utilidad y existencia. La Calidad del Software es mensurable y varía de un sistema a otro o de un programa a otro. Por ejemplo: un software elaborado para el control de naves espaciales debe ser confiable afallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más) necesita ser confiable, mantenible y flexible py perfeccionamiento durante el tiempo de explotación.

Aspectos de la Calidad La Calidad del Software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su contdurante todas las etapas del ciclo de vida del software. Objetivo de la Calidad en los Sistemas El Objetivo que persigue la Calidad en los Sistemas está orientada a:

• Incrementar la productividad y satisfacción al trabajo de los profesionales afines campo de la computación.

• Mejorar la calidad del producto del software.• Proveer técnicas aplicadas para automatizar el manejo de datos.

CALIDAD DE SOFTWARE

Diferenciaremos dos conceptos importantes como son:

calidad de sistemas está orientado a garantizar el funcionamiento de los sistemas en explotación.

calidad de software está orientado a garantizar las características de los programas que se están desarrollando.

La Ingeniería de Software concierne a teorías, métodos y herramientas para el desarrollo profesional de productos. Un Sistema concierne a un conjunto de componentes

dos trabajando conjuntamente para un fin común. El sistema puede incluir software, dispositivos mecánicos y eléctricos, hardware, y ser operado por gente. Existen varias organizaciones de estandarización internacional que realizan estándares y modelos de ngeniería de software, esto con el fin de mejorar la Calidad del Software.

La ISO (International Standard Organization), define La Calidad como la ausencia de

"Es la totalidad de aspectos y características de un producto o servicio que se refieren a su capacidad para satisfacer necesidades dadas en la adecuación de sus objetivos'”.El Instituto de Ingeniería de Software (SEI) en su modelo CMM (Capability Maturity Model)

El grado en el cual un sistema, componente o proceso cumple con los requisitos

El grado en el cual el sistema, componente o proceso cumple con las expectativas del cliente o usuario. La calidad consiste en todos aquellos aspectos del producto que satisfacen las

cliente y de ese modo proporcionan la satisfacción del producto.

La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La Calidad del Software es el conjunto de

ualidades que lo caracterizan y que determinan su utilidad y existencia. La Calidad del Software es mensurable y varía de un sistema a otro o de un programa a otro. Por ejemplo: un software elaborado para el control de naves espaciales debe ser confiable afallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más) necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación.

del Software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su contdurante todas las etapas del ciclo de vida del software.

Objetivo de la Calidad en los Sistemas

El Objetivo que persigue la Calidad en los Sistemas está orientada a:

Incrementar la productividad y satisfacción al trabajo de los profesionales afines campo de la computación. Mejorar la calidad del producto del software. Proveer técnicas aplicadas para automatizar el manejo de datos.

CALIDAD DE SOFTWARE

9

está orientado a garantizar el funcionamiento de

garantizar las características de

La Ingeniería de Software concierne a teorías, métodos y herramientas para el desarrollo profesional de productos. Un Sistema concierne a un conjunto de componentes

dos trabajando conjuntamente para un fin común. El sistema puede incluir software, dispositivos mecánicos y eléctricos, hardware, y ser operado por gente. Existen varias organizaciones de estandarización internacional que realizan estándares y modelos de ngeniería de software, esto con el fin de mejorar la Calidad del Software.

La ISO (International Standard Organization), define La Calidad como la ausencia de

io que se refieren a su capacidad para satisfacer necesidades dadas en la adecuación de sus objetivos'”. El Instituto de Ingeniería de Software (SEI) en su modelo CMM (Capability Maturity Model)

onente o proceso cumple con los requisitos

El grado en el cual el sistema, componente o proceso cumple con las expectativas del

La calidad consiste en todos aquellos aspectos del producto que satisfacen las cliente y de ese modo proporcionan la satisfacción del producto.

La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, La Calidad del Software es el conjunto de

ualidades que lo caracterizan y que determinan su utilidad y existencia. La Calidad del Software es mensurable y varía de un sistema a otro o de un programa a otro. Por ejemplo: un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o

ara disminuir los costos de mantenimiento

del Software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control

Incrementar la productividad y satisfacción al trabajo de los profesionales afines al


• Realizar una planeación eficaz de los sistemas.• Documentar. • Validar y controlar formalmente la calidad del trabajo rea• Cumplir con los objetivos de la organización en cuanto a productividad de sus

sistemas de cómputo. Obtención de un Software de Calidad La obtención de un Software con Calidad implica la utilización de metodologías o procedimientos estándares parapermitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la Calidad del Software.

• El principio tecnológico software.

• El principio administrativo desarrollo del software, así como la organización del ambiente o centro de ingeniería de software.

• El principio ergonómico automatizado. Para el aseguramiento de la calidad es necesario su control o evaluación.

Control de la Calidad El Control de la Calidad es realizar una observación constante acerca del cumplimiento de las tareas que pueden ofrecer una calidad objetiva a la forma en proyecto de Ingeniería de Software. Es decir, undesarrollo y ciclo de vida del software. Esta meta puede alcanzarse mediante frecuentes inspecciones a las metodologías de trabajo y uso de herramientas, revisiones de prototipos y evaluación exhaustiva de los prectificaciones pertinentes al desarrollo en cuanto éste empieza a desviarse de sus objetivos, por lo tanto, de la calidad del trabajo. Estas rectificaciones son posibles gracias a una retroalimentación de las etapas superiores, creado así un aprendizaje al observar las salidas de cada etapa, hasta el producto final, y mejorar los procesos que dan origen al sistema.En el Control de Calidad deben tenerse presentes los costos que esta involucra.en las tareas que deben realizarse en este control, puede observase que es necesario llevar a cabo tareas de búsqueda de problemas, evaluación, realimentación, rectificación, elaboración, modificación y estudio de la documentación; entre otra Pero debe existir un compromiso, ya que un excesivo costo en el control de la calidad puede hacer que este proceso se torne ineficiente. Pero, por otra parte, el mejoramiento de la calidad implica reducir los costos ya que se tendría un cieFinalmente, y como consecuencia de la naturaleza del proceso de desarrollo de productos software, el asegurar la calidad en las primeras etapas de este involucra que los costos del control en las etapas posteriores tenderpues, nuevamente, la calidad estaría asegurada en sus bases.

Control de Calidad del Software Para controlar la Calidad del Software es necesario, definir los parámetros, indicadores o criterios de medición. El software posee determinados índices mensurables que son las bases para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados los índices de calidad, debe establecerse el proceso de control, que requiere los siguiepasos:

CALIDAD DE SOFTWARE

Realizar una planeación eficaz de los sistemas.

Validar y controlar formalmente la calidad del trabajo realizado. Cumplir con los objetivos de la organización en cuanto a productividad de sus sistemas de cómputo.

Obtención de un Software de Calidad

btención de un Software con Calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software, que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor

lo como para el control de la Calidad del Software.

principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del

principio administrativo contempla las funciones de planificación y control del software, así como la organización del ambiente o centro de ingeniería

principio ergonómico define la interfaz entre el usuario y el ambiente automatizado. Para el aseguramiento de la calidad es necesario su control o

El Control de la Calidad es realizar una observación constante acerca del cumplimiento de las tareas que pueden ofrecer una calidad objetiva a la forma en cómo se está desarrollando un proyecto de Ingeniería de Software. Es decir, una vigilancia permanente a todo el proceso de desarrollo y ciclo de vida del software. Esta meta puede alcanzarse mediante frecuentes inspecciones a las metodologías de trabajo y uso de herramientas, revisiones de prototipos y evaluación exhaustiva de los productos finales. El Control de la Calidad permite realizar las rectificaciones pertinentes al desarrollo en cuanto éste empieza a desviarse de sus objetivos, por lo tanto, de la calidad del trabajo. Estas rectificaciones son posibles gracias a una

imentación de las etapas superiores, creado así un aprendizaje al observar las salidas de cada etapa, hasta el producto final, y mejorar los procesos que dan origen al sistema.En el Control de Calidad deben tenerse presentes los costos que esta involucra.en las tareas que deben realizarse en este control, puede observase que es necesario llevar a cabo tareas de búsqueda de problemas, evaluación, realimentación, rectificación, elaboración, modificación y estudio de la documentación; entre otras actividades.

Pero debe existir un compromiso, ya que un excesivo costo en el control de la calidad puede hacer que este proceso se torne ineficiente. Pero, por otra parte, el mejoramiento de la calidad implica reducir los costos ya que se tendría un cierto nivel de calidad ya asegurado. Finalmente, y como consecuencia de la naturaleza del proceso de desarrollo de productos software, el asegurar la calidad en las primeras etapas de este involucra que los costos del control en las etapas posteriores tenderá a disminuir al tener menos aspectos que controlar pues, nuevamente, la calidad estaría asegurada en sus bases.

Control de Calidad del Software

Para controlar la Calidad del Software es necesario, definir los parámetros, indicadores o ión. El software posee determinados índices mensurables que son las bases

para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados los índices de calidad, debe establecerse el proceso de control, que requiere los siguie

CALIDAD DE SOFTWARE

10

Cumplir con los objetivos de la organización en cuanto a productividad de sus

btención de un Software con Calidad implica la utilización de metodologías o el análisis, diseño, programación y prueba del software, que

permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor

define las técnicas a utilizar en el proceso de desarrollo del

contempla las funciones de planificación y control del software, así como la organización del ambiente o centro de ingeniería

define la interfaz entre el usuario y el ambiente automatizado. Para el aseguramiento de la calidad es necesario su control o

El Control de la Calidad es realizar una observación constante acerca del cumplimiento de las se está desarrollando un

a vigilancia permanente a todo el proceso de desarrollo y ciclo de vida del software. Esta meta puede alcanzarse mediante frecuentes inspecciones a las metodologías de trabajo y uso de herramientas, revisiones de prototipos y

roductos finales. El Control de la Calidad permite realizar las rectificaciones pertinentes al desarrollo en cuanto éste empieza a desviarse de sus objetivos, por lo tanto, de la calidad del trabajo. Estas rectificaciones son posibles gracias a una

imentación de las etapas superiores, creado así un aprendizaje al observar las salidas de cada etapa, hasta el producto final, y mejorar los procesos que dan origen al sistema. En el Control de Calidad deben tenerse presentes los costos que esta involucra. Si se piensa en las tareas que deben realizarse en este control, puede observase que es necesario llevar a cabo tareas de búsqueda de problemas, evaluación, realimentación, rectificación, elaboración,

Pero debe existir un compromiso, ya que un excesivo costo en el control de la calidad puede hacer que este proceso se torne ineficiente. Pero, por otra parte, el mejoramiento de la

rto nivel de calidad ya asegurado. Finalmente, y como consecuencia de la naturaleza del proceso de desarrollo de productos software, el asegurar la calidad en las primeras etapas de este involucra que los costos del

á a disminuir al tener menos aspectos que controlar

Para controlar la Calidad del Software es necesario, definir los parámetros, indicadores o ión. El software posee determinados índices mensurables que son las bases

para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados los índices de calidad, debe establecerse el proceso de control, que requiere los siguientes


1. Definir el software que va a ser controladoaplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.

2. Seleccionar una medida que pueda ser aplicada al objeto dclase de software es necesario definir los indicadores y sus magnitudes.

3. Crear o determinar los métodos de valoración de los indicadoresmanuales, como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo.

4. Definir las regulaciones organizativas para realizar el controlen el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.

Indicadores para diferenciar los productos de calidad de los que carecen de ella:

• El acercamiento a cero defectos.• El cumplimiento de los requisitos intrínsecos y expresos.• La satisfacción del cliente

La Calidad del Software debe ser una disciplina más dentro de la Ingeniería del software. El principal instrumento para garantizar la calidad de las aplicaciones sigue siendo el Plan de Calidad. El plan se basa en unas normas o estándares genéricos y en unos procediparticulares. Las normas, directivas, modelos y estándares son básicamente las siguientes:

• Familia de normas ISO 9000 y en especial, la ISO 9001 y la ISO 9000Quality Management and Quality Assurance Standards

• ISO 8402: 1994 • IEEE 730/1984, Standard for Software Quality Assurance Plans• IEEE Std 1028: 1989, IEEE Standard for Software Reviews and Audits• CMM. Capability Maturity Model• ISO/IEC JTC1 15504. SPICE. Software Process Improvement and Capability

Determination. • Modelo de EFQM.

Los procedimientos pueden variar en cada organización, pero lo importante es que estén escritos, personalizados, adaptados a los procesos de la organización y, lo que es más importante, que se cumplan.el ciclo de vida, debe correr paralela desde la planificación del producto hasta la fase de producción del mismo. Capacidades del Software Las capacidades importantes para un producto de softwusuario, así como los factores que determinan la calidad de cada una de las capacidades son:

• Capacidad de operación con los factores de corrección, facilidad, eficiencia, integridad y facilidad de uso.

• Capacidad para ser de prueba y facilidad de mantenimiento.

• Capacidad de transición o de adaptación a otros entornos con los factores de transportabilidad, capacidad de reutilización y de interoperación.

Calidad Total en el Proceso de Desarrollo del Sistema Para alcanzar la "Calidad Total", es necesaria la satisfacción por parte de los elementos que intervienen en el proceso:

CALIDAD DE SOFTWARE

Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software. Seleccionar una medida que pueda ser aplicada al objeto de controlclase de software es necesario definir los indicadores y sus magnitudes.Crear o determinar los métodos de valoración de los indicadoresmanuales, como cuestionarios o encuestas estándares para la medición de criterios

les y herramientas automatizadas para medir los criterios de cálculo.Definir las regulaciones organizativas para realizar el controlen el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y


l acercamiento a cero defectos. El cumplimiento de los requisitos intrínsecos y expresos. La satisfacción del cliente

del Software debe ser una disciplina más dentro de la Ingeniería del software. El principal instrumento para garantizar la calidad de las aplicaciones sigue siendo el Plan de Calidad. El plan se basa en unas normas o estándares genéricos y en unos procedi

Las normas, directivas, modelos y estándares son básicamente las siguientes:

Familia de normas ISO 9000 y en especial, la ISO 9001 y la ISO 9000Quality Management and Quality Assurance Standards

730/1984, Standard for Software Quality Assurance Plans

IEEE Std 1028: 1989, IEEE Standard for Software Reviews and AuditsCMM. Capability Maturity Model ISO/IEC JTC1 15504. SPICE. Software Process Improvement and Capability

Modelo de EFQM. Modelo de la Fundación Europea de Gestión de Calidad

Los procedimientos pueden variar en cada organización, pero lo importante es que estén escritos, personalizados, adaptados a los procesos de la organización y, lo que es más importante, que se cumplan. La Calidad del Software debe implementarse a lo largo de todo el ciclo de vida, debe correr paralela desde la planificación del producto hasta la fase de

Capacidades del Software

Las capacidades importantes para un producto de software desde el punto de vista del usuario, así como los factores que determinan la calidad de cada una de las capacidades son:

Capacidad de operación con los factores de corrección, facilidad, eficiencia, integridad y facilidad de uso. Capacidad para ser modificado o de revisión con los factores de flexibilidad, facilidad de prueba y facilidad de mantenimiento. Capacidad de transición o de adaptación a otros entornos con los factores de transportabilidad, capacidad de reutilización y de interoperación.

lidad Total en el Proceso de Desarrollo del Sistema

Para alcanzar la "Calidad Total", es necesaria la satisfacción por parte de los elementos que intervienen en el proceso:

CALIDAD DE SOFTWARE

11

: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el

e control. Para cada clase de software es necesario definir los indicadores y sus magnitudes. Crear o determinar los métodos de valoración de los indicadores: métodos manuales, como cuestionarios o encuestas estándares para la medición de criterios

les y herramientas automatizadas para medir los criterios de cálculo. Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y


del Software debe ser una disciplina más dentro de la Ingeniería del software. El principal instrumento para garantizar la calidad de las aplicaciones sigue siendo el Plan de Calidad. El plan se basa en unas normas o estándares genéricos y en unos procedimientos

Las normas, directivas, modelos y estándares son básicamente las siguientes:

Familia de normas ISO 9000 y en especial, la ISO 9001 y la ISO 9000-3.2:1996

IEEE Std 1028: 1989, IEEE Standard for Software Reviews and Audits

ISO/IEC JTC1 15504. SPICE. Software Process Improvement and Capability

Modelo de la Fundación Europea de Gestión de Calidad

Los procedimientos pueden variar en cada organización, pero lo importante es que estén escritos, personalizados, adaptados a los procesos de la organización y, lo que es más

La Calidad del Software debe implementarse a lo largo de todo el ciclo de vida, debe correr paralela desde la planificación del producto hasta la fase de

are desde el punto de vista del usuario, así como los factores que determinan la calidad de cada una de las capacidades son:

Capacidad de operación con los factores de corrección, facilidad, eficiencia, integridad

modificado o de revisión con los factores de flexibilidad, facilidad

Capacidad de transición o de adaptación a otros entornos con los factores de

Para alcanzar la "Calidad Total", es necesaria la satisfacción por parte de los elementos que


• La satisfacción de la alta dirección• La satisfacción del personal involucrado en • La satisfacción del usuario final

La aplicación del control de calidad de sistemas no es solamente al sistema en sí, ésta conforma la última parte de la evaluación. Elementos para el Proceso de Sistemas Son tres los elementos qdeben de considerarse para el mejor control de calidad y realización de los sistemas, estos son:

1. Gente 2. Herramientas (Software y Hardware)3. Tiempo disponible

Debe contarse con la gente trabajo, las herramientas de trabajo deben ser confiables, no limitadas y debe tomarse en cuenta cuanto tiempo se dispone para la elaboración del sistema. Componentes para la Calidad Total

• Claridad • Involucración • Planeamiento • Estándares • Entrenamiento • Experiencia • Controles • Documentación • Soporte • Finalización

Claridad La definición de lo que se tiene que hacer o lo que el usuario necesita, debe ser clara para todos los responsables del proyecto Involucración Es necesario revisar cada etapa del proyecto. Para cada una de ellas es importante dejar en claro si vale la pena continuar o no, si hay limitaciones o restricciones que afecten o impidan el buen funcionamiento del proyecto y si se está dando el cubrimiento adecuado a todos los requerimientos y funciones, divisiones o departamentos que están involucrados en la realización del proyecto. Planeamiento En la planificación intervienen tanto los usDebe planearse el grado de integración que se requiere en las diferentes áreas de la organización, para interpretar necesidades o requerimientos satisfactorios con el objeto de llegar a acuerdos en caso dcual vamos a poner a trabajar alguna etapa o actividad en el proyecto. Estándares Tiene que tomarse en cuenta la forma mediante la cual vamos a trabajar desde el punto de vista tecnológico, ya que es necesario tener presente la definición de diversos factores que afectarían la realización del proyecto, como son:

CALIDAD DE SOFTWARE

La satisfacción de la alta dirección La satisfacción del personal involucrado en el desarrollo del sistemaLa satisfacción del usuario final

La aplicación del control de calidad de sistemas no es solamente al sistema en sí, ésta conforma la última parte de la evaluación.

Elementos para el Proceso de Sistemas

Son tres los elementos que integran el proceso de sistemas, los cuales por su importancia deben de considerarse para el mejor control de calidad y realización de los sistemas, estos

Herramientas (Software y Hardware) Tiempo disponible

Debe contarse con la gente adecuada, que tenga la suficiente capacidad para realizar el trabajo, las herramientas de trabajo deben ser confiables, no limitadas y debe tomarse en cuenta cuanto tiempo se dispone para la elaboración del sistema.

Componentes para la Calidad Total

La definición de lo que se tiene que hacer o lo que el usuario necesita, debe ser clara para todos los responsables del proyecto, esto con el fin de establecer reglas a seguir.

Es necesario revisar cada etapa del proyecto. Para cada una de ellas es importante dejar en claro si vale la pena continuar o no, si hay limitaciones o restricciones que afecten o impidan

buen funcionamiento del proyecto y si se está dando el cubrimiento adecuado a todos los requerimientos y funciones, divisiones o departamentos que están involucrados en la

En la planificación intervienen tanto los usuarios como el personal que desarrolle el proyecto. Debe planearse el grado de integración que se requiere en las diferentes áreas de la organización, para interpretar necesidades o requerimientos satisfactorios con el objeto de llegar a acuerdos en caso de imprevistos en asuntos tan simples como el método mediante el cual vamos a poner a trabajar alguna etapa o actividad en el proyecto.

Tiene que tomarse en cuenta la forma mediante la cual vamos a trabajar desde el punto de a que es necesario tener presente la definición de diversos factores que

afectarían la realización del proyecto, como son:

CALIDAD DE SOFTWARE

12

el desarrollo del sistema

La aplicación del control de calidad de sistemas no es solamente al sistema en sí, ésta

ue integran el proceso de sistemas, los cuales por su importancia deben de considerarse para el mejor control de calidad y realización de los sistemas, estos

adecuada, que tenga la suficiente capacidad para realizar el trabajo, las herramientas de trabajo deben ser confiables, no limitadas y debe tomarse en

La definición de lo que se tiene que hacer o lo que el usuario necesita, debe ser clara para , esto con el fin de establecer reglas a seguir.

Es necesario revisar cada etapa del proyecto. Para cada una de ellas es importante dejar en claro si vale la pena continuar o no, si hay limitaciones o restricciones que afecten o impidan

buen funcionamiento del proyecto y si se está dando el cubrimiento adecuado a todos los requerimientos y funciones, divisiones o departamentos que están involucrados en la

uarios como el personal que desarrolle el proyecto. Debe planearse el grado de integración que se requiere en las diferentes áreas de la organización, para interpretar necesidades o requerimientos satisfactorios con el objeto de

e imprevistos en asuntos tan simples como el método mediante el

Tiene que tomarse en cuenta la forma mediante la cual vamos a trabajar desde el punto de a que es necesario tener presente la definición de diversos factores que


• Lenguaje de programación• Manejo de librerías• Código • Instrucciones • Comentarios • Administración de backups• Administración de archivos• Periodicidad de revisiones• Documentación

Debe quedar clara su definición, los elementos que los deben integrar, así como su estandarización. Sin una estandarización el proyecto se vendría abajo. Entrenamiento El entrenamiento es un factor determinante paramediante él se obtienen los conocimientos y habilidades que se aplicarán en el proyecto. Experiencia El contar con mucha o poca experiencia, determina el tiempo de desarrollo del sistema así como la calidad del trabajo que realice (oportunidad Controles Los controles que se establezcan deben realizarse con alguna periodicidad. Primeramente debe verse el avance del proyecto; el cumplimiento de los requerimientos del cliente; el seguimiento y las normapara el proyecto; el funcionamiento de la aplicación; del desarrollo con el usuario y un punto importante es la mutua satisfacción entre de la gente que realiza el proyecto con el usuarEn este caso puede contarse con un Calendario de Entrega donde contenga los puntos anteriormente mencionados, así como contar con Bitácoras que respalden las reuniones que se tengan con los usuarios y los acuerdos a los que hayan llegado ambas partes. Documentación Es importante que la documentación que se genere debe ser clara y útil en cuanto al sistema, ya sean los programas, las tareas del usuario y sus procedimientos, el manejo de la aplicación y producción y los cuidados con respecto a backde historia respecto a fallas, mejoras, arreglos, etc., contribuyen a una mejor utilización del sistema, es decir, a una mayor calidad en su operación. Manuales de usuario, técnico y de operación. Soporte Es indispensable tener claro quién nos puede apoyar en las áreas técnica, de análisis, en el área usuaria, ya sea en la instalación, en el área ejecutiva o en algún otro aspecto, ya que las aplicaciones en los proyectos de sistemas enfrentan siempre necesidades crít Finalización La finalización del proyecto de un sistema es una de las labores más importantes en el desarrollo del mismo, de igual manera que en cada etapa. En la finalización del proyecto es necesario considerar cinco puntos vitales:

• La revisión de todos los pasos realizados y de las etapas incluidas en el proceso total;• Elaboración del proceso en forma integral;• Calidad hecha en cada uno de los pasos o etapas del proyecto;• La atención a los requerimientos del usuario en términos de hace

quiera, o más; • Y, por supuesto, la satisfacción de nuestro usuario o cliente que, en últimas, es el

reconocimiento a la labor bien realizada y de alta calidad.

CALIDAD DE SOFTWARE

Lenguaje de programación Manejo de librerías

Administración de backups Administración de archivos

riodicidad de revisiones

Debe quedar clara su definición, los elementos que los deben integrar, así como su estandarización. Sin una estandarización el proyecto se vendría abajo.

El entrenamiento es un factor determinante para la realización de un proyecto, ya que mediante él se obtienen los conocimientos y habilidades que se aplicarán en el proyecto.

El contar con mucha o poca experiencia, determina el tiempo de desarrollo del sistema así trabajo que realice (oportunidad - calidad).

Los controles que se establezcan deben realizarse con alguna periodicidad. Primeramente debe verse el avance del proyecto; el cumplimiento de los requerimientos del cliente; el seguimiento y las normas de seguridad y de auditoríaa; la involucración de las personas clave para el proyecto; el funcionamiento de la aplicación; del desarrollo con el usuario y un punto importante es la mutua satisfacción entre de la gente que realiza el proyecto con el usuarEn este caso puede contarse con un Calendario de Entrega donde contenga los puntos anteriormente mencionados, así como contar con Bitácoras que respalden las reuniones que se tengan con los usuarios y los acuerdos a los que hayan llegado ambas partes.

Es importante que la documentación que se genere debe ser clara y útil en cuanto al sistema, ya sean los programas, las tareas del usuario y sus procedimientos, el manejo de la aplicación y producción y los cuidados con respecto a back-ups, ayudas y soporte requerido, la bitácora de historia respecto a fallas, mejoras, arreglos, etc., contribuyen a una mejor utilización del sistema, es decir, a una mayor calidad en su operación. Manuales de usuario, técnico y de

nsable tener claro quién nos puede apoyar en las áreas técnica, de análisis, en el área usuaria, ya sea en la instalación, en el área ejecutiva o en algún otro aspecto, ya que las aplicaciones en los proyectos de sistemas enfrentan siempre necesidades crít

La finalización del proyecto de un sistema es una de las labores más importantes en el desarrollo del mismo, de igual manera que en cada etapa. En la finalización del proyecto es necesario considerar cinco puntos vitales:

revisión de todos los pasos realizados y de las etapas incluidas en el proceso total;Elaboración del proceso en forma integral; Calidad hecha en cada uno de los pasos o etapas del proyecto; La atención a los requerimientos del usuario en términos de hace

Y, por supuesto, la satisfacción de nuestro usuario o cliente que, en últimas, es el reconocimiento a la labor bien realizada y de alta calidad.

CALIDAD DE SOFTWARE

13

Debe quedar clara su definición, los elementos que los deben integrar, así como su

la realización de un proyecto, ya que mediante él se obtienen los conocimientos y habilidades que se aplicarán en el proyecto.

El contar con mucha o poca experiencia, determina el tiempo de desarrollo del sistema así

Los controles que se establezcan deben realizarse con alguna periodicidad. Primeramente debe verse el avance del proyecto; el cumplimiento de los requerimientos del cliente; el

s de seguridad y de auditoríaa; la involucración de las personas clave para el proyecto; el funcionamiento de la aplicación; del desarrollo con el usuario y un punto importante es la mutua satisfacción entre de la gente que realiza el proyecto con el usuario. En este caso puede contarse con un Calendario de Entrega donde contenga los puntos anteriormente mencionados, así como contar con Bitácoras que respalden las reuniones que se tengan con los usuarios y los acuerdos a los que hayan llegado ambas partes.

Es importante que la documentación que se genere debe ser clara y útil en cuanto al sistema, ya sean los programas, las tareas del usuario y sus procedimientos, el manejo de la aplicación

ayudas y soporte requerido, la bitácora de historia respecto a fallas, mejoras, arreglos, etc., contribuyen a una mejor utilización del sistema, es decir, a una mayor calidad en su operación. Manuales de usuario, técnico y de

nsable tener claro quién nos puede apoyar en las áreas técnica, de análisis, en el área usuaria, ya sea en la instalación, en el área ejecutiva o en algún otro aspecto, ya que las aplicaciones en los proyectos de sistemas enfrentan siempre necesidades críticas de soporte.

La finalización del proyecto de un sistema es una de las labores más importantes en el desarrollo del mismo, de igual manera que en cada etapa. En la finalización del proyecto es

revisión de todos los pasos realizados y de las etapas incluidas en el proceso total;

La atención a los requerimientos del usuario en términos de hacer todo lo que él

Y, por supuesto, la satisfacción de nuestro usuario o cliente que, en últimas, es el


Cuando se desarrolle un sistema o aplicación y se instale, debe asegurarse de manera que lo que se entregue esté completo, sea oportuno, no tenga errores, sea confiable, útil y estable.

Administración de la Calidad La Administración de la Calidad cuenta con dos niveles de trabajo: El nivel de entidad u organizacióninfraestructura que fomente la calidad de los productos software mediante la adecuación y mejora de las actividades y procesos involucrados en su producción e, incluso, en su comercialización y en la interacción co El nivel del proyecto. distintas actividades y mantenimiento del software deben ser adaptadas a las características concretas del proyecto y de su entorno para ser aplicadanivel de acción, la gestión de la calidad en organizaciones de software ha seguido dos líneas que pueden ser complementarias entre sí: Por una parte, se ha seguido la línea marcada por las entidades internacionales de esto servicios. Principalmente se han impuesto en la práctica las directrices marcadas por ISO (Organization for International Standardization) a través de unas normas ISO 9000 para la gestión de calidad. En el caso del software es principalmente aplicable la norma ISO 9001.sector de software difiere por la naturaleza del producto tanto del resto de sectores productivos que ha sido necesario crear una guía específica para su aplicación a este sector: ISO 9000-3. El mundo del software ha creado sus propias líneas de trabajocalidad, trabaja sobre los procesos de producción como medio para asegurar la calidad del producto software. Por ejemplo, el SEI (Software Engineering Institute), proponiendo un modelo de clasificación y mejora de los procesos empleadosoftware denominado CMM.nunca al final. A mayor calidad, mayores son los costos, pero mayores también los beneficios obtenidos en la fase del mantenimiento del sofde todo el ciclo de vida del proyecto. El aseguramiento de la Calidad de Software engloba un enfoque de gestión de calidad, tecnología de ingeniería de software efectiva (métricas y herramientas), revisiones téuna estrategia de prueba multiescalada, el control de la documentación del software y de los cambios realizados, un procedimiento que asegure un ajuste a los estándares de desarrollo del software (cuando sea posible) y mecanismos de medición y de generación de informes. La Prueba del Software Se pueden realizar inspecciones para cada módulo o pequeño grupo de módulos que conformen un sistema. Al limitar el centro de atención de la RTF la proberrores es mayor. Calidad en el Diseño Aquí se plantean características definidas para la realización del producto software que deberán cumplirse posteriormente. La calidad se basa en definir un listado de especificaciones a seguir. Involucra descripción de los procesos, tareas y responsabilidades de los equipos de desarrollo. En esta etapa la calidad aumenta en la medida en que se realiza una alta especificación de los procesos y se propone una estrecha tolerancia a la modificación,estableciendo los métodos correctivos a las desviaciones ocurridas. Esta es la medida de la calidad apreciada por los usuarios finales del entendimiento del producto software. Estas apreciaciones de calidad hacia un determinado producto elevarán el nivel organización desarrolladora, lo que puede elevar su posición en el mercado.

CALIDAD DE SOFTWARE

Cuando se desarrolle un sistema o aplicación y se instale, debe asegurarse de manera que lo que se entregue esté completo, sea oportuno, no tenga errores, sea confiable,

La Administración de la Calidad cuenta con dos niveles de trabajo:

El nivel de entidad u organización. Donde se trata de crear y gestionar una infraestructura que fomente la calidad de los productos software mediante la adecuación y mejora de las actividades y procesos involucrados en su producción e, incluso, en su comercialización y en la interacción con los clientes.

. Donde las guías que la infraestructura organizativa prevé para las distintas actividades y mantenimiento del software deben ser adaptadas a las características concretas del proyecto y de su entorno para ser aplicadas a la práctica. Dentro del primer nivel de acción, la gestión de la calidad en organizaciones de software ha seguido dos líneas que pueden ser complementarias entre sí: Por una parte, se ha seguido la línea marcada por las entidades internacionales de estandarización para todas las organizaciones de producción o servicios. Principalmente se han impuesto en la práctica las directrices marcadas por ISO (Organization for International Standardization) a través de unas normas ISO 9000 para la

d. En el caso del software es principalmente aplicable la norma ISO 9001.sector de software difiere por la naturaleza del producto tanto del resto de sectores productivos que ha sido necesario crear una guía específica para su aplicación a este sector:

3. El mundo del software ha creado sus propias líneas de trabajocalidad, trabaja sobre los procesos de producción como medio para asegurar la calidad del producto software. Por ejemplo, el SEI (Software Engineering Institute), proponiendo un modelo de clasificación y mejora de los procesos empleados por las organizaciones de software denominado CMM. La Calidad del Software se diseña conjuntamente con el sistema, nunca al final. A mayor calidad, mayores son los costos, pero mayores también los beneficios obtenidos en la fase del mantenimiento del software. Este costo hay que considerarlo dentro de todo el ciclo de vida del proyecto. El aseguramiento de la Calidad de Software engloba un enfoque de gestión de calidad, tecnología de ingeniería de software efectiva (métricas y herramientas), revisiones técnicas formales que se aplican durante el proceso del software, una estrategia de prueba multiescalada, el control de la documentación del software y de los cambios realizados, un procedimiento que asegure un ajuste a los estándares de desarrollo

are (cuando sea posible) y mecanismos de medición y de generación de informes.

Prueba del Software

Se pueden realizar inspecciones para cada módulo o pequeño grupo de módulos que conformen un sistema. Al limitar el centro de atención de la RTF la prob

Aquí se plantean características definidas para la realización del producto software que deberán cumplirse posteriormente. La calidad se basa en definir un listado de especificaciones

Involucra descripción de los procesos, tareas y responsabilidades de los equipos de En esta etapa la calidad aumenta en la medida en que se realiza una alta

especificación de los procesos y se propone una estrecha tolerancia a la modificación,estableciendo los métodos correctivos a las desviaciones ocurridas. Esta es la medida de la calidad apreciada por los usuarios finales del entendimiento del producto software. Estas apreciaciones de calidad hacia un determinado producto elevarán el nivel organización desarrolladora, lo que puede elevar su posición en el mercado.

CALIDAD DE SOFTWARE

14

Cuando se desarrolle un sistema o aplicación y se instale, debe asegurarse de hacerlo de tal manera que lo que se entregue esté completo, sea oportuno, no tenga errores, sea confiable,

Donde se trata de crear y gestionar una infraestructura que fomente la calidad de los productos software mediante la adecuación y mejora de las actividades y procesos involucrados en su producción e, incluso, en su

Donde las guías que la infraestructura organizativa prevé para las distintas actividades y mantenimiento del software deben ser adaptadas a las características

s a la práctica. Dentro del primer nivel de acción, la gestión de la calidad en organizaciones de software ha seguido dos líneas que pueden ser complementarias entre sí: Por una parte, se ha seguido la línea marcada por

andarización para todas las organizaciones de producción o servicios. Principalmente se han impuesto en la práctica las directrices marcadas por ISO (Organization for International Standardization) a través de unas normas ISO 9000 para la

d. En el caso del software es principalmente aplicable la norma ISO 9001. El sector de software difiere por la naturaleza del producto tanto del resto de sectores productivos que ha sido necesario crear una guía específica para su aplicación a este sector:

3. El mundo del software ha creado sus propias líneas de trabajo en la gestión de la calidad, trabaja sobre los procesos de producción como medio para asegurar la calidad del producto software. Por ejemplo, el SEI (Software Engineering Institute), proponiendo un

s por las organizaciones de La Calidad del Software se diseña conjuntamente con el sistema,

nunca al final. A mayor calidad, mayores son los costos, pero mayores también los beneficios tware. Este costo hay que considerarlo dentro

de todo el ciclo de vida del proyecto. El aseguramiento de la Calidad de Software engloba un enfoque de gestión de calidad, tecnología de ingeniería de software efectiva (métricas y

cnicas formales que se aplican durante el proceso del software, una estrategia de prueba multiescalada, el control de la documentación del software y de los cambios realizados, un procedimiento que asegure un ajuste a los estándares de desarrollo

are (cuando sea posible) y mecanismos de medición y de generación de informes.

Se pueden realizar inspecciones para cada módulo o pequeño grupo de módulos que conformen un sistema. Al limitar el centro de atención de la RTF la probabilidad de descubrir

Aquí se plantean características definidas para la realización del producto software que deberán cumplirse posteriormente. La calidad se basa en definir un listado de especificaciones

Involucra descripción de los procesos, tareas y responsabilidades de los equipos de En esta etapa la calidad aumenta en la medida en que se realiza una alta

especificación de los procesos y se propone una estrecha tolerancia a la modificación, estableciendo los métodos correctivos a las desviaciones ocurridas. Esta es la medida de la calidad apreciada por los usuarios finales del entendimiento del producto software. Estas apreciaciones de calidad hacia un determinado producto elevarán el nivel de confianza para la organización desarrolladora, lo que puede elevar su posición en el mercado.


UNIDAD DIDÁCTICA N° MODELOS Y ESTÁNDARES

LOS CINCO MODELOS MÁS ACREDITADOS E Introducción

La estandarización es toda actividad documentada que norma el comportamiento de un grupo de personas. Los estándares nos dan los medios para que todos los procesos se realicen siempre de la misma forma, mientras nos surjan ideas para mejorarlos. Son nuestra gla productividad y la calidad. Expectativas de los estándares:

• Mejora de procesos de software acorde a los objetivos estratégicos• Mejora de los productos• Protección del cliente o usuario• Protección de la organización (cultura de la organización y

Existen varias organizaciones de estandarización internacional, algunas son regionales mientras que otras son globales. Las últimas están relacionadas con la ONU o son independientes, como por ejemplo la International Telecommunication ULa International Electrotechnical Commission (IEC) que fue fundada en el año 1906 para definir estándares en eléctrica y electrónica, mientras que la Internacional Organization for Standardization (ISO) fue creada en 1947 para abarcar otros temobjetivo facilitar el intercambio de bienes y servicios a nivel internacional, entre otras. En 1987, ISO e IEC decidieron formar el Joint Technical Commit (JTC), cuyo objetivo es elaborar estándares para la tecnología de información Incomo la ISO, BOOTSTRAP, entre otras se han dedicado a crear modelos para mejorar la Calidad del Software, entre ellos tenemos:

• ISO 9000 • CMM (Estados Unidos)• Tick It (Inglaterra)• Bootstrap (Europa)• ISO/SPICE (Australia)

La Norma ISO 9000

La Organización Internacional para la Estandarización (ISO) fue fundada el 23 de febrero de 1947 con el objetivo de crear una norma internacional de calidad. El Comité Técnico ISO/TC 176 para Aseguramiento de la Calidad fue El objetivo del estándar es desarrollar un código mínimo que contenga prácticas de administración para garantizar el Aseguramiento y Administración de la Calidad, es decir, qué hacer para responder a los requerideben responder los proveedores y compradores respecto a la calidad de los bienes o servicios intercambiados.estándar deseado, así comse establecen.

CALIDAD DE SOFTWARE


Y ESTÁNDARES DE CALIDAD DE SOFTWARE

LOS CINCO MODELOS MÁS ACREDITADOS EN CALIDAD DE SOFTWARE

estandarización es toda actividad documentada que norma el comportamiento de un grupo de personas. Los estándares nos dan los medios para que todos los procesos se realicen siempre de la misma forma, mientras nos surjan ideas para mejorarlos. Son nuestra gla productividad y la calidad.

Expectativas de los estándares: Mejora de procesos de software acorde a los objetivos estratégicosMejora de los productos Protección del cliente o usuario Protección de la organización (cultura de la organización y mejora continua)

Existen varias organizaciones de estandarización internacional, algunas son regionales mientras que otras son globales. Las últimas están relacionadas con la ONU o son independientes, como por ejemplo la International Telecommunication Union (ITU).La International Electrotechnical Commission (IEC) que fue fundada en el año 1906 para definir estándares en eléctrica y electrónica, mientras que la Internacional Organization for Standardization (ISO) fue creada en 1947 para abarcar otros temas. Ambas tienen por objetivo facilitar el intercambio de bienes y servicios a nivel internacional, entre otras. En 1987, ISO e IEC decidieron formar el Joint Technical Commit (JTC), cuyo objetivo es elaborar estándares para la tecnología de información Information Technology (IT). Organizaciones como la ISO, BOOTSTRAP, entre otras se han dedicado a crear modelos para mejorar la Calidad del Software, entre ellos tenemos:

CMM (Estados Unidos) Tick It (Inglaterra) Bootstrap (Europa)

(Australia)

La Organización Internacional para la Estandarización (ISO) fue fundada el 23 de febrero de 1947 con el objetivo de crear una norma internacional de calidad. El Comité Técnico ISO/TC 176 para Aseguramiento de la Calidad fue el encargado de crear el estándar ISO 9000.

El objetivo del estándar es desarrollar un código mínimo que contenga prácticas de administración para garantizar el Aseguramiento y Administración de la Calidad, es decir, qué hacer para responder a los requerimientos de un mercado cada vez más competitivo y cómo deben responder los proveedores y compradores respecto a la calidad de los bienes o servicios intercambiados. Para ello establece una serie de guías para la selección y uso del estándar deseado, así como aclara conceptos en cuanto a la calidad y las interrelaciones que

CALIDAD DE SOFTWARE

15

DE CALIDAD DE SOFTWARE

CALIDAD DE SOFTWARE

estandarización es toda actividad documentada que norma el comportamiento de un grupo de personas. Los estándares nos dan los medios para que todos los procesos se realicen siempre de la misma forma, mientras nos surjan ideas para mejorarlos. Son nuestra guía para

Mejora de procesos de software acorde a los objetivos estratégicos

mejora continua)

Existen varias organizaciones de estandarización internacional, algunas son regionales mientras que otras son globales. Las últimas están relacionadas con la ONU o son

nion (ITU). La International Electrotechnical Commission (IEC) que fue fundada en el año 1906 para definir estándares en eléctrica y electrónica, mientras que la Internacional Organization for

as. Ambas tienen por objetivo facilitar el intercambio de bienes y servicios a nivel internacional, entre otras. En 1987, ISO e IEC decidieron formar el Joint Technical Commit (JTC), cuyo objetivo es elaborar

formation Technology (IT). Organizaciones como la ISO, BOOTSTRAP, entre otras se han dedicado a crear modelos para mejorar la

La Organización Internacional para la Estandarización (ISO) fue fundada el 23 de febrero de 1947 con el objetivo de crear una norma internacional de calidad. El Comité Técnico ISO/TC

el encargado de crear el estándar ISO 9000.

El objetivo del estándar es desarrollar un código mínimo que contenga prácticas de administración para garantizar el Aseguramiento y Administración de la Calidad, es decir, qué

mientos de un mercado cada vez más competitivo y cómo deben responder los proveedores y compradores respecto a la calidad de los bienes o

Para ello establece una serie de guías para la selección y uso del o aclara conceptos en cuanto a la calidad y las interrelaciones que


Estructura General De forma general la norma se divide en 4 guías o modelos fundamentales:

• ISO 9001 Sistemas de Calidad. Modelo de Aseguramiento de la Calidaddesarrollo, producción, instalación y servicio.

• ISO 9002 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad para la producción, instalación y servicio.

• ISO 9003 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad para la inspección final y pruebas.

• ISO 9004 Elementos para la Administración y el Sistema de Calidad. Guía para el Sistema de Aseguramiento de la Calidad.

Además, existen otras normas y entre ellas las más relevantes son:

• ISO 9000-1 Guía para la selección de la • ISO 8402 Recopilación de definiciones. Vocabulario.• ISO 9000-3 Estándares de Administración y Aseguramiento de la Calidad.

De forma general los requerimientos fundamentales de ISO 9000 son:

• Escribir un manual de calidad, describiendo el Sis• Escribir documentos en forma de procedimientos que describan cómo debe hacerse el

trabajo en la organización.• Crear un sistema para controlar la distribución y reedición de documentos.• Diseño e implantación de un sistema de a

prevenir la ocurrencia de problemas.• Identificar las necesidades en cuanto a entrenamiento en la organización.• Determinar las medidas y equipos para realizar las pruebas.• Capacitar al personal de la organización en la• Planificar y llevar a cabo auditorias de calidad internas.• Tener en cuenta los requerimientos del estándar con los que no cumple la

organización. Los factores que determinan el modelo a elegir son: a) La complejidad del pr

servicio cuando éste no ha sido diseñado.b) La madurez del diseño. Se proyecta hacia el conocimiento y aprobación del diseño total,

ya sea por las pruebas de desempeño o por la c) La complejidad del proceso de producción. Está relacionado con la capacidad del proceso

de producción, las necesidades de desarrollo del nuevo proceso, las variaciones que se requieren y el impacto en el desempeño del producto o se

d) Las características del producto o servicio. Depende de la complejidad del producto o servicio, del número de características interrelacionadas y de su influencia en el desempeño.

e) La seguridad del producto o servicio. Relacionado con el riesgo de oimpacto de éstas.

El Modelo CMM

A principios de los años 80’s el Departamento de Defensa de los Estados Unidos enfocó sus tareas a la revisión de los problemas del software y a su mejoramiento. Ingeniería de Software (SEI) a finales de 1984. Como parte de su trabajo, el Instituto se dio a la tarea de desarrollar el comenzó el Proyecto de Evaluación de la Capacidad del Software. Después de varios años

CALIDAD DE SOFTWARE

De forma general la norma se divide en 4 guías o modelos fundamentales:

ISO 9001 Sistemas de Calidad. Modelo de Aseguramiento de la Calidaddesarrollo, producción, instalación y servicio. ISO 9002 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad para la producción, instalación y servicio. ISO 9003 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad para la

cción final y pruebas. ISO 9004 Elementos para la Administración y el Sistema de Calidad. Guía para el Sistema de Aseguramiento de la Calidad.

Además, existen otras normas y entre ellas las más relevantes son:

1 Guía para la selección de la norma a usar. ISO 8402 Recopilación de definiciones. Vocabulario.

3 Estándares de Administración y Aseguramiento de la Calidad.

De forma general los requerimientos fundamentales de ISO 9000 son:

Escribir un manual de calidad, describiendo el Sistema de Calidad en alto nivel.Escribir documentos en forma de procedimientos que describan cómo debe hacerse el trabajo en la organización. Crear un sistema para controlar la distribución y reedición de documentos.Diseño e implantación de un sistema de acciones preventivas y correctivas para prevenir la ocurrencia de problemas. Identificar las necesidades en cuanto a entrenamiento en la organización.Determinar las medidas y equipos para realizar las pruebas. Capacitar al personal de la organización en la operación del Sistema de Calidad.Planificar y llevar a cabo auditorias de calidad internas. Tener en cuenta los requerimientos del estándar con los que no cumple la

Los factores que determinan el modelo a elegir son:

La complejidad del proceso de diseño. Se refiere a la dificultad para diseñar el producto o servicio cuando éste no ha sido diseñado. La madurez del diseño. Se proyecta hacia el conocimiento y aprobación del diseño total, ya sea por las pruebas de desempeño o por la experiencia en el campo.La complejidad del proceso de producción. Está relacionado con la capacidad del proceso de producción, las necesidades de desarrollo del nuevo proceso, las variaciones que se requieren y el impacto en el desempeño del producto o servicio. Las características del producto o servicio. Depende de la complejidad del producto o servicio, del número de características interrelacionadas y de su influencia en el

La seguridad del producto o servicio. Relacionado con el riesgo de ocurrencia de fallas y el

A principios de los años 80’s el Departamento de Defensa de los Estados Unidos enfocó sus tareas a la revisión de los problemas del software y a su mejoramiento. S

de Software (SEI) a finales de 1984. Como parte de su trabajo, el Instituto se dio a la tarea de desarrollar el Modelo de Madurez del Proceso de Software comenzó el Proyecto de Evaluación de la Capacidad del Software. Después de varios años

CALIDAD DE SOFTWARE

16

De forma general la norma se divide en 4 guías o modelos fundamentales:

ISO 9001 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad en el diseño,

ISO 9002 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad para la

ISO 9003 Sistemas de Calidad. Modelo de Aseguramiento de la Calidad para la

ISO 9004 Elementos para la Administración y el Sistema de Calidad. Guía para el

3 Estándares de Administración y Aseguramiento de la Calidad.

tema de Calidad en alto nivel. Escribir documentos en forma de procedimientos que describan cómo debe hacerse el

Crear un sistema para controlar la distribución y reedición de documentos. cciones preventivas y correctivas para

Identificar las necesidades en cuanto a entrenamiento en la organización.

operación del Sistema de Calidad.

Tener en cuenta los requerimientos del estándar con los que no cumple la

oceso de diseño. Se refiere a la dificultad para diseñar el producto o

La madurez del diseño. Se proyecta hacia el conocimiento y aprobación del diseño total, experiencia en el campo.

La complejidad del proceso de producción. Está relacionado con la capacidad del proceso de producción, las necesidades de desarrollo del nuevo proceso, las variaciones que se

Las características del producto o servicio. Depende de la complejidad del producto o servicio, del número de características interrelacionadas y de su influencia en el

currencia de fallas y el

A principios de los años 80’s el Departamento de Defensa de los Estados Unidos enfocó sus Se creó el Instituto de

de Software (SEI) a finales de 1984. Como parte de su trabajo, el Instituto se dio a Modelo de Madurez del Proceso de Software y para 1986 se

comenzó el Proyecto de Evaluación de la Capacidad del Software. Después de varios años de


realizar cuestionarios, evaluaciones, consulta e investigación, junto a otras organizaciones, en 1991 SEI produce el Modelo de Capacidad y Madurez del Software.El Modelo de Madurez y Capacidad del Proceso de Software (CMM) ayuda a que las organizaciones para producir de manera consistente y predecible productos de calidad superior. La capacidad del proceso es la habilidad inherente para producir los resultados planeados. El principal objetivo de un proceso de software maduro es el de producir productos de calidad que cumplan los requerimientos del usuario. Cuando se habla de madurez se entiende como el crecimiento alcanzado en la capacidad del proceso de software y que se considera como una actividad a largo plazo. En una organización de software inmaduexisten planes rigurosos, se enfocan en resolver las crisis que se le presentan, carecen de bases objetivas para enjuiciar la calidad de los productos o para resolver los problemas. Por lo contrario cuando la organización alcanza cierto grado de madurez posee una gran habilidad para administrar el proceso de desarrollo y mantenimiento del software, se hacen pruebas y análisis de costo-beneficio para mejorar el proceso, el administrador monitorea la producto y la satisfacción del cliente, se llevan registros y todos los integrantes están involucrados. La madurez del proceso de software esta dada cuando un proceso en específico es explícitamente definido, administrado, medido, controlado ypropone las bases para el trabajo de mejoramiento del proceso. Este consta de 4 pasos que se repiten en forma de ciclo hasta que la implantación produce los resultados esperados y los cambios pasan a ser permanentes.Los pasos son:

1. Planear

2. Ejecutar

3. Revisar

4. Actuar

CMM es un modelo descriptivo en el sentido que describe los atributos esenciales que se espera caractericen una organización dentro de un nivel de madurez en particular. Es un modelo normativo ya que las prácticas detalladas caracterizan el tcomportamiento que se espera de una organización que realiza proyectos a gran escala. No es prescriptivo ya que no dice a la organización como mejorar. Estructura del modelo El modelo consta de 5 niveles, diseñados de forma que los cimientos incrementados de manera progresiva sobre los que se construyen los niveles superiores. Estas 5 etapas de desarrollo son referidas como niveles de madurez y en cada una la organización alcanza una capacidad en el p Los 5 niveles del modelo son:

CALIDAD DE SOFTWARE

realizar cuestionarios, evaluaciones, consulta e investigación, junto a otras organizaciones, en 1991 SEI produce el Modelo de Capacidad y Madurez del Software. El Modelo de Madurez y Capacidad del Proceso de Software (CMM) ayuda a que las

s para producir de manera consistente y predecible productos de calidad superior. La capacidad del proceso es la habilidad inherente para producir los resultados planeados. El principal objetivo de un proceso de software maduro es el de producir productos de calidad que cumplan los requerimientos del usuario.

Cuando se habla de madurez se entiende como el crecimiento alcanzado en la capacidad del proceso de software y que se considera como una actividad a largo plazo. En una organización de software inmadura, el proceso de software es generalmente improvisado, no existen planes rigurosos, se enfocan en resolver las crisis que se le presentan, carecen de bases objetivas para enjuiciar la calidad de los productos o para resolver los problemas. Por lo

o cuando la organización alcanza cierto grado de madurez posee una gran habilidad para administrar el proceso de desarrollo y mantenimiento del software, se hacen pruebas y

beneficio para mejorar el proceso, el administrador monitorea la producto y la satisfacción del cliente, se llevan registros y todos los integrantes están

La madurez del proceso de software esta dada cuando un proceso en específico es explícitamente definido, administrado, medido, controlado y es efectivo. El ciclo Shewhart propone las bases para el trabajo de mejoramiento del proceso. Este consta de 4 pasos que se repiten en forma de ciclo hasta que la implantación produce los resultados esperados y los cambios pasan a ser permanentes.

Planear a. Definir el problema b. Establecer los objetivos a mejorar

Ejecutar a. Identificar las posibles causas de problemasb. Establecer las bases c. Probar los cambios

Revisar a. Recolectar los datos b. Evaluar los datos

Actuar a. Implementar los cambios b. Determinar la efectividad

CMM es un modelo descriptivo en el sentido que describe los atributos esenciales que se espera caractericen una organización dentro de un nivel de madurez en particular. Es un modelo normativo ya que las prácticas detalladas caracterizan el tcomportamiento que se espera de una organización que realiza proyectos a gran escala.

No es prescriptivo ya que no dice a la organización como mejorar.

Estructura del modelo

El modelo consta de 5 niveles, diseñados de forma que los inferiores proveen unos fuertes cimientos incrementados de manera progresiva sobre los que se construyen los niveles

Estas 5 etapas de desarrollo son referidas como niveles de madurez y en cada una la organización alcanza una capacidad en el proceso superior.

Los 5 niveles del modelo son:

CALIDAD DE SOFTWARE

17

realizar cuestionarios, evaluaciones, consulta e investigación, junto a otras organizaciones, en

El Modelo de Madurez y Capacidad del Proceso de Software (CMM) ayuda a que las s para producir de manera consistente y predecible productos de calidad

superior. La capacidad del proceso es la habilidad inherente para producir los resultados planeados. El principal objetivo de un proceso de software maduro es el de producir productos

Cuando se habla de madurez se entiende como el crecimiento alcanzado en la capacidad del proceso de software y que se considera como una actividad a largo plazo. En una

ra, el proceso de software es generalmente improvisado, no existen planes rigurosos, se enfocan en resolver las crisis que se le presentan, carecen de bases objetivas para enjuiciar la calidad de los productos o para resolver los problemas. Por lo

o cuando la organización alcanza cierto grado de madurez posee una gran habilidad para administrar el proceso de desarrollo y mantenimiento del software, se hacen pruebas y

beneficio para mejorar el proceso, el administrador monitorea la calidad del producto y la satisfacción del cliente, se llevan registros y todos los integrantes están

La madurez del proceso de software esta dada cuando un proceso en específico es es efectivo. El ciclo Shewhart

propone las bases para el trabajo de mejoramiento del proceso. Este consta de 4 pasos que se repiten en forma de ciclo hasta que la implantación produce los resultados esperados y los

Identificar las posibles causas de problemas

CMM es un modelo descriptivo en el sentido que describe los atributos esenciales que se espera caractericen una organización dentro de un nivel de madurez en particular. Es un modelo normativo ya que las prácticas detalladas caracterizan el tipo normal de comportamiento que se espera de una organización que realiza proyectos a gran escala.

inferiores proveen unos fuertes cimientos incrementados de manera progresiva sobre los que se construyen los niveles

Estas 5 etapas de desarrollo son referidas como niveles de madurez y en cada una la


1. Inicial: el proceso de software es un proceso improvisado y caótico. Pocos procesos

están definidos y el éxito que se pueda obtener depende de las habilidades, conocimientos y motivaciones del personal. No costos y las funcionalidades y calidad del producto son impredecibles. No existe un ambiente estable para el desarrollo y mantenimiento del software. El proceso del software es impredecible por el continuo cambio o modifel trabajo.

2. Repetible: se establecen procedimientos de administración del proceso básico para determinar costos, calendarios y funcionalidades. Se establecen las políticas para la administración del proceso y los procedimientos en repetir éxitos anteriores en proyectos de similares características, por lo que los mayores riesgos se presentan cuando se enfrentan a nuevos proyectos. Se exhiben problemas de calidad y carecen de una adecuada estruc

3. Definido: el proceso de software para las actividades administrativas y técnicas está documentado, homogeneizado e integrado en un proceso de software estándar dentro de la organización, que ayudará a obtener un desempeño más efectivo.grupo que trabaja en el proceso enfoca y guía sus esfuerzos al mejoramiento de su desarrollo, facilita la introducción de técnicas y métodos e informa a la administración del estado del proceso. La capacidad del proceso está basada en una amplia comprensión común dentro de la organización de las actividades, roles y responsabilidades definidas en el desarrollo de software.

4. Administrativocalidad del producto. Ambos son cuantitativamente ede Shewhart es constantemente utilizado para planear, implementar y registrar las mejoras al proceso. Este nivel de capacidad permite a la organización predecir las tendencias en la calidad del producto dentro de los límitacciones necesarias en caso que sean excedidos. Los productos de dicha categoría son predeciblemente de alta calidad.

5. Optimización: retroalimentación cuantitativa y desdinnovadoras. La organización tiene los medios para identificar los puntos débiles y conocer como fortalecerlos. Su actividad clave es el análisis de las causas de defectos y su prevención.

El Modelo Tick IT

El Departamento de Comercio e Industria del Reino Unido (DTI: Department of Trade and Industry) creó el esquema Tick IT. Los objetivos primordiales de éste fueron, además de desarrollar un sistema de certificación aceptable en el mercado, estimular a los desarrolladores de software a implementar sistemas de calidad, dando la dirección y guías necesarias para tal efecto.responsabilidad actual por el esquema Tick IT se pasó a DISC, que es una oficina dependiede British Standards Institution (BSI) Standards Division, siendo esta última la única autoridad en el Reino Unido para publicar estándares. Ciclo de Vida del Software Un sistema de calidad típico Tickcontinuación:

• Elaboración de propuestas y revisión de contratos asegurando que todos los requerimientos estén bien especificados y de que la organización tiene la capacidad para cumplirlos.

• Análisis y especificación de los requerimientos del sistema asegurando que sean revisados y acordados con el cliente.

CALIDAD DE SOFTWARE

el proceso de software es un proceso improvisado y caótico. Pocos procesos están definidos y el éxito que se pueda obtener depende de las habilidades, conocimientos y motivaciones del personal. No existen calendarios ni estimados de costos y las funcionalidades y calidad del producto son impredecibles. No existe un ambiente estable para el desarrollo y mantenimiento del software. El proceso del software es impredecible por el continuo cambio o modificación a medida que avanza

se establecen procedimientos de administración del proceso básico para determinar costos, calendarios y funcionalidades. Se establecen las políticas para la administración del proceso y los procedimientos de implantación. El proceso se basa en repetir éxitos anteriores en proyectos de similares características, por lo que los mayores riesgos se presentan cuando se enfrentan a nuevos proyectos. Se exhiben problemas de calidad y carecen de una adecuada estructura para mejorarla.

el proceso de software para las actividades administrativas y técnicas está documentado, homogeneizado e integrado en un proceso de software estándar dentro de la organización, que ayudará a obtener un desempeño más efectivo.grupo que trabaja en el proceso enfoca y guía sus esfuerzos al mejoramiento de su desarrollo, facilita la introducción de técnicas y métodos e informa a la administración del estado del proceso. La capacidad del proceso está basada en una amplia

nsión común dentro de la organización de las actividades, roles y responsabilidades definidas en el desarrollo de software. Administrativo: se recolectan medidas detalladas del proceso de software y de la calidad del producto. Ambos son cuantitativamente entendidos y controlados. El ciclo de Shewhart es constantemente utilizado para planear, implementar y registrar las mejoras al proceso. Este nivel de capacidad permite a la organización predecir las tendencias en la calidad del producto dentro de los límites establecidos y tomar las acciones necesarias en caso que sean excedidos. Los productos de dicha categoría son predeciblemente de alta calidad.

: el mejoramiento continuo del proceso es garantizado por la retroalimentación cuantitativa y desde las pruebas de técnicas y herramientas innovadoras. La organización tiene los medios para identificar los puntos débiles y conocer como fortalecerlos. Su actividad clave es el análisis de las causas de defectos

artamento de Comercio e Industria del Reino Unido (DTI: Department of Trade and Industry) creó el esquema Tick IT. Los objetivos primordiales de éste fueron, además de desarrollar un sistema de certificación aceptable en el mercado, estimular a los

lladores de software a implementar sistemas de calidad, dando la dirección y guías necesarias para tal efecto. Aunque el proyecto original estuvo a cargo del DTI1, la responsabilidad actual por el esquema Tick IT se pasó a DISC, que es una oficina dependiede British Standards Institution (BSI) Standards Division, siendo esta última la única autoridad en el Reino Unido para publicar estándares.

Ciclo de Vida del Software

Un sistema de calidad típico Tick IT deberá contener los elementos que se enlistan a

Elaboración de propuestas y revisión de contratos asegurando que todos los requerimientos estén bien especificados y de que la organización tiene la capacidad

pecificación de los requerimientos del sistema asegurando que sean

revisados y acordados con el cliente.

CALIDAD DE SOFTWARE

18

el proceso de software es un proceso improvisado y caótico. Pocos procesos están definidos y el éxito que se pueda obtener depende de las habilidades,

existen calendarios ni estimados de costos y las funcionalidades y calidad del producto son impredecibles. No existe un ambiente estable para el desarrollo y mantenimiento del software. El proceso del

icación a medida que avanza

se establecen procedimientos de administración del proceso básico para determinar costos, calendarios y funcionalidades. Se establecen las políticas para la

de implantación. El proceso se basa en repetir éxitos anteriores en proyectos de similares características, por lo que los mayores riesgos se presentan cuando se enfrentan a nuevos proyectos. Se exhiben

tura para mejorarla. el proceso de software para las actividades administrativas y técnicas está

documentado, homogeneizado e integrado en un proceso de software estándar dentro de la organización, que ayudará a obtener un desempeño más efectivo. El grupo que trabaja en el proceso enfoca y guía sus esfuerzos al mejoramiento de su desarrollo, facilita la introducción de técnicas y métodos e informa a la administración del estado del proceso. La capacidad del proceso está basada en una amplia

nsión común dentro de la organización de las actividades, roles y

se recolectan medidas detalladas del proceso de software y de la ntendidos y controlados. El ciclo

de Shewhart es constantemente utilizado para planear, implementar y registrar las mejoras al proceso. Este nivel de capacidad permite a la organización predecir las

es establecidos y tomar las acciones necesarias en caso que sean excedidos. Los productos de dicha categoría

el mejoramiento continuo del proceso es garantizado por la e las pruebas de técnicas y herramientas

innovadoras. La organización tiene los medios para identificar los puntos débiles y conocer como fortalecerlos. Su actividad clave es el análisis de las causas de defectos

artamento de Comercio e Industria del Reino Unido (DTI: Department of Trade and Industry) creó el esquema Tick IT. Los objetivos primordiales de éste fueron, además de desarrollar un sistema de certificación aceptable en el mercado, estimular a los

lladores de software a implementar sistemas de calidad, dando la dirección y guías Aunque el proyecto original estuvo a cargo del DTI1, la

responsabilidad actual por el esquema Tick IT se pasó a DISC, que es una oficina dependiente de British Standards Institution (BSI) Standards Division, siendo esta última la única autoridad

IT deberá contener los elementos que se enlistan a

Elaboración de propuestas y revisión de contratos asegurando que todos los requerimientos estén bien especificados y de que la organización tiene la capacidad

pecificación de los requerimientos del sistema asegurando que sean


• Planeación, control y monitoreo del avance del desarrollo respecto al plan comunicando a todas las partes afectadas y que avise oportunamente de problepotenciales.

• Planeación de la calidad del proyecto, especificando las inspecciones, revisiones y pruebas requeridas durante el desarrollo.

• Inspecciones de los productos contra estándares y requerimientos aplicables y las acciones correctivas

• Diseño de primer nivel identificando los componentes principales y los requerimientos que satisfacen.

• Diseño detallado de todos los componentes e interfaces, construcción, y prueba de los mismos verificando que satisfagan la especificació

• Integración, pruebas e inspecciones del sistema, demostrando que el sistema integrado funciona correctamente y satisface su especificación.

• Identificar, segregar, investigar y corregir productos no conformes.• Auditorias, pruebas e inspecciones de acepta

que el sistema satisface los requerimientos.• Almacenamiento, replicación, envío e instalación, asegurando la integridad y

seguridad de los productos, así como el cumplimiento de los compromisos adquiridos con el cliente.

• Puesta en marcha y liberación del producto para disponibilidad del cliente.• Entrenamiento a usuarios en el uso del sistema de tal manera que pueda operarlo y

beneficiarse completamente del mismo con la mínima intervención del proveedor.• Mantenimiento o sustitución del sistema, asegurando que se continúa operando en

conformidad con los requerimientos del cliente o usuario.• Soporte a clientes de acuerdo a lo especificado en el contrato.

Soporte y Aseguramiento de Calidad

• Establecer políticas y objetivopara alinearla en todas sus actividades, procedimientos y políticas específicas.

• Implantar y mantener un sistema de aseguramiento de calidad.• Auditorias, revisiones y acciones correctivas al sistema de c

sistema cumple con los requerimientos, es utilizado y que es efectivo en el logro de resultados.

• Definir, recolectar y analizar datos de calidad para evaluar la efectividad del sistema de calidad e identificar mejoras potenciales

• Administración de la organización y los proyectos de tal forma que facilite los resultados de calidad.

• Administración de la configuración que identifique y controle, de manera continua, las partes constituyentes y sus versiones, de cada instancia de un s

• Respaldos, seguridad y almacenamiento que protejan contra cualquier pérdida o corrupción.

• Sistema de control de registros y documentación para todas las actividades de aseguramiento de calidad, de los proyectos y de soporte, incluyendoregistros.

• Especificación y control del proceso de desarrollo incluyendo técnicas, prácticas, convenciones, estándares, mediciones y estadísticas.

• Proceso de compras, incluyendo identificación, selección, adquisición y aceptación que asegure que los bienes y servicios adquiridos sean como se requiere y de calidad aceptable.

• Control de productos incluidos, equipo y herramientas utilizadas: Hardware o Software, adquiridos o suministrados por el cliente, incluyendo utilización, configuración, seguridad.

• Entrenamiento, reclutamiento y desarrollo de personal que asegure su competencia y motivación, y disminuya su rotación.

CALIDAD DE SOFTWARE

Planeación, control y monitoreo del avance del desarrollo respecto al plan comunicando a todas las partes afectadas y que avise oportunamente de proble

Planeación de la calidad del proyecto, especificando las inspecciones, revisiones y pruebas requeridas durante el desarrollo. Inspecciones de los productos contra estándares y requerimientos aplicables y las acciones correctivas correspondientes. Diseño de primer nivel identificando los componentes principales y los requerimientos

Diseño detallado de todos los componentes e interfaces, construcción, y prueba de los mismos verificando que satisfagan la especificación. Integración, pruebas e inspecciones del sistema, demostrando que el sistema integrado funciona correctamente y satisface su especificación. Identificar, segregar, investigar y corregir productos no conformes.Auditorias, pruebas e inspecciones de aceptación del sistema demostrando al cliente que el sistema satisface los requerimientos. Almacenamiento, replicación, envío e instalación, asegurando la integridad y seguridad de los productos, así como el cumplimiento de los compromisos adquiridos

Puesta en marcha y liberación del producto para disponibilidad del cliente.Entrenamiento a usuarios en el uso del sistema de tal manera que pueda operarlo y beneficiarse completamente del mismo con la mínima intervención del proveedor.

o sustitución del sistema, asegurando que se continúa operando en conformidad con los requerimientos del cliente o usuario. Soporte a clientes de acuerdo a lo especificado en el contrato.

Soporte y Aseguramiento de Calidad

Establecer políticas y objetivos de calidad generales de la organización que sirvan para alinearla en todas sus actividades, procedimientos y políticas específicas.Implantar y mantener un sistema de aseguramiento de calidad. Auditorias, revisiones y acciones correctivas al sistema de calidad que aseguren que el sistema cumple con los requerimientos, es utilizado y que es efectivo en el logro de

Definir, recolectar y analizar datos de calidad para evaluar la efectividad del sistema de calidad e identificar mejoras potenciales. Administración de la organización y los proyectos de tal forma que facilite los resultados de calidad. Administración de la configuración que identifique y controle, de manera continua, las partes constituyentes y sus versiones, de cada instancia de un sistema o subsistema.Respaldos, seguridad y almacenamiento que protejan contra cualquier pérdida o

Sistema de control de registros y documentación para todas las actividades de aseguramiento de calidad, de los proyectos y de soporte, incluyendo

Especificación y control del proceso de desarrollo incluyendo técnicas, prácticas, convenciones, estándares, mediciones y estadísticas. Proceso de compras, incluyendo identificación, selección, adquisición y aceptación que

ure que los bienes y servicios adquiridos sean como se requiere y de calidad

Control de productos incluidos, equipo y herramientas utilizadas: Hardware o Software, adquiridos o suministrados por el cliente, incluyendo utilización,

seguridad. Entrenamiento, reclutamiento y desarrollo de personal que asegure su competencia y motivación, y disminuya su rotación.

CALIDAD DE SOFTWARE

19

Planeación, control y monitoreo del avance del desarrollo respecto al plan comunicando a todas las partes afectadas y que avise oportunamente de problemas

Planeación de la calidad del proyecto, especificando las inspecciones, revisiones y

Inspecciones de los productos contra estándares y requerimientos aplicables y las

Diseño de primer nivel identificando los componentes principales y los requerimientos

Diseño detallado de todos los componentes e interfaces, construcción, y prueba de los

Integración, pruebas e inspecciones del sistema, demostrando que el sistema

Identificar, segregar, investigar y corregir productos no conformes. ción del sistema demostrando al cliente

Almacenamiento, replicación, envío e instalación, asegurando la integridad y seguridad de los productos, así como el cumplimiento de los compromisos adquiridos

Puesta en marcha y liberación del producto para disponibilidad del cliente. Entrenamiento a usuarios en el uso del sistema de tal manera que pueda operarlo y beneficiarse completamente del mismo con la mínima intervención del proveedor.

o sustitución del sistema, asegurando que se continúa operando en

s de calidad generales de la organización que sirvan para alinearla en todas sus actividades, procedimientos y políticas específicas.

alidad que aseguren que el sistema cumple con los requerimientos, es utilizado y que es efectivo en el logro de

Definir, recolectar y analizar datos de calidad para evaluar la efectividad del sistema

Administración de la organización y los proyectos de tal forma que facilite los

Administración de la configuración que identifique y controle, de manera continua, las istema o subsistema.

Respaldos, seguridad y almacenamiento que protejan contra cualquier pérdida o

Sistema de control de registros y documentación para todas las actividades de aseguramiento de calidad, de los proyectos y de soporte, incluyendo procedimientos y

Especificación y control del proceso de desarrollo incluyendo técnicas, prácticas,

Proceso de compras, incluyendo identificación, selección, adquisición y aceptación que ure que los bienes y servicios adquiridos sean como se requiere y de calidad

Control de productos incluidos, equipo y herramientas utilizadas: Hardware o Software, adquiridos o suministrados por el cliente, incluyendo utilización,

Entrenamiento, reclutamiento y desarrollo de personal que asegure su competencia y


El Modelo BOOTSTRAP

El Instituto Bootstrap es una organización no lucrativa dedicada a la mejora continua del modelo de calidad de software llamado BOOTSTRAP, también tiene como propósito ayudar a la industria europea del software para mejorar su competitividad. Bootstrap es un método para analizar, rediseñar y mejorar los procesos de negocio del desarrollo de software. Este se compone de: un modelo, un proceso de evaluación, una base de datos de soporte, un proceso de mejora y los instrumentos de evaluación. Su enfoque es evaluar el proceso, no el producto. Para eso se definen un conjunto de características para los procesosanálisis cuantitativo, produce vistas analíticas, hace evidente fortalezas y debilidades, identifica áreas de mejora, provee recomendaciones y sugiere un plan de implementación. El modelo define el paradigma Organizaciónpara los niveles de evaluación y agrupación de resultados.El modelo Bootstrap se basa en evaluar las unidades de producción de software de la organización, a través de sus proyectos para hacer un cambio a toda la organización. Dentprincipales: preparación, ejecución de la evaluación, determinación del nivel de madurez y capacidades, y la presentación de resultados de la evaluación En la etapa de preparación

1. un entrenamiento inicial para tener claros los objetivos2. se seleccionan los proyectos a ser evaluados para obtener la mejor cobertura de la

UPS 3. se define el personal de evaluación para minimizar la subjetividad4. se define el personal a ser evaluado para

involucrados en los proyectos seleccionados y5. se hace el acuerdo de confidencialidad.

En la etapa de ejecución

1. una breve reunión de apertura, para obtener un enfoque colaborativo con el personal

a ser entrevistado;2. el llenado de los cuestionarios con características generales de la UPS;3. el llenado de los cuestionarios del proyecto elegido, incluyendo la evaluación de cómo

el proceso de producción es aplicado;4. revisión preliminar de la evaluación, y5. reunión final, con el enfoque de presentar los resultados de la evaluación y obtener el

consenso para poder pasar a la fase de mejoras. En la etapa de determinar el nivel de madurez y capacidadespregunta con uno de 5 valores posibles: nulo, débil, regular, extenso o no aplica. Para cada atributo clave se obtiene un nivel de madurez, aplicando un algoritmo numérico, dando como resultado uno de estos niveles: 1optimizado. Estos niveles de madurez están subdivididos en cuatro, de forma que se obtenga una calificación más exacta. Los procesos de organización y metodología se califican de 1 a 5, mientras que el de tecnolog Como resultado de la evaluaciónde la evaluación de la UPS y otro con los resultados del proyecto evaluado. El correspondiente a la UPS contiene informacpuntos débiles y fuertes, un plan de acción recomendado, etc. El reporte del proyecto contiene: comentarios del proyecto actual detallando lo referente a la organización, metodología y tecnologíarecomendado, etc.

CALIDAD DE SOFTWARE

El Instituto Bootstrap es una organización no lucrativa dedicada a la mejora continua del lidad de software llamado BOOTSTRAP, también tiene como propósito ayudar a

la industria europea del software para mejorar su competitividad. Bootstrap es un método para analizar, rediseñar y mejorar los procesos de negocio del desarrollo de software.

se compone de: un modelo, un proceso de evaluación, una base de datos de soporte, un proceso de mejora y los instrumentos de evaluación. Su enfoque es evaluar el proceso, no el producto. Para eso se definen un conjunto de características para los procesosanálisis cuantitativo, produce vistas analíticas, hace evidente fortalezas y debilidades, identifica áreas de mejora, provee recomendaciones y sugiere un plan de implementación. El modelo define el paradigma Organización-Metodología- Tecnología que se usa en Bootstrap para los niveles de evaluación y agrupación de resultados.El modelo Bootstrap se basa en evaluar las unidades de producción de software de la organización, a través de sus proyectos para hacer un cambio a toda la organización. Dentro de este proceso, hay cuatro etapas

preparación, ejecución de la evaluación, determinación del nivel de madurez y capacidades, y la presentación de resultados de la evaluación.

etapa de preparación se realizan las siguientes tareas:

un entrenamiento inicial para tener claros los objetivos se seleccionan los proyectos a ser evaluados para obtener la mejor cobertura de la

se define el personal de evaluación para minimizar la subjetividadse define el personal a ser evaluado para obtener la mejor cobertura de los roles involucrados en los proyectos seleccionados y se hace el acuerdo de confidencialidad.

etapa de ejecución, las tareas son:

na breve reunión de apertura, para obtener un enfoque colaborativo con el personal ser entrevistado;

el llenado de los cuestionarios con características generales de la UPS;el llenado de los cuestionarios del proyecto elegido, incluyendo la evaluación de cómo el proceso de producción es aplicado; revisión preliminar de la evaluación, y reunión final, con el enfoque de presentar los resultados de la evaluación y obtener el consenso para poder pasar a la fase de mejoras.

etapa de determinar el nivel de madurez y capacidades, es donde se califica cada pregunta con uno de 5 valores posibles: nulo, débil, regular, extenso o no aplica. Para cada atributo clave se obtiene un nivel de madurez, aplicando un algoritmo numérico, dando como resultado uno de estos niveles: 1-inicial, 2-repetible, 3-definido, 4optimizado. Estos niveles de madurez están subdivididos en cuatro, de forma que se obtenga una calificación más exacta. Los procesos de organización y metodología se califican de 1 a 5, mientras que el de tecnología se califica sólo con dos niveles A o B.

resultado de la evaluación, la organización recibe 2 reportes, uno con los resultados de la evaluación de la UPS y otro con los resultados del proyecto evaluado. El correspondiente a la UPS contiene información como: un resumen ejecutivo, los objetivos de la UPS, los puntos débiles y fuertes, un plan de acción recomendado, etc. El reporte del proyecto contiene: comentarios del proyecto actual detallando lo referente a la organización, metodología y tecnología, los niveles de madurez para el proyecto, el plan de acción

CALIDAD DE SOFTWARE

20

El Instituto Bootstrap es una organización no lucrativa dedicada a la mejora continua del lidad de software llamado BOOTSTRAP, también tiene como propósito ayudar a

la industria europea del software para mejorar su competitividad. Bootstrap es un método para analizar, rediseñar y mejorar los procesos de negocio del desarrollo de software.

se compone de: un modelo, un proceso de evaluación, una base de datos de soporte, un proceso de mejora y los instrumentos de evaluación. Su enfoque es evaluar el proceso, no el producto. Para eso se definen un conjunto de características para los procesos, provee un análisis cuantitativo, produce vistas analíticas, hace evidente fortalezas y debilidades, identifica áreas de mejora, provee recomendaciones y sugiere un plan de implementación. El

que se usa en Bootstrap para los niveles de evaluación y agrupación de resultados.El modelo Bootstrap se basa en evaluar las unidades de producción de software de la organización, a través de sus proyectos

ro de este proceso, hay cuatro etapas preparación, ejecución de la evaluación, determinación del nivel de madurez y

se seleccionan los proyectos a ser evaluados para obtener la mejor cobertura de la

se define el personal de evaluación para minimizar la subjetividad obtener la mejor cobertura de los roles

na breve reunión de apertura, para obtener un enfoque colaborativo con el personal

el llenado de los cuestionarios con características generales de la UPS; el llenado de los cuestionarios del proyecto elegido, incluyendo la evaluación de cómo

reunión final, con el enfoque de presentar los resultados de la evaluación y obtener el

, es donde se califica cada pregunta con uno de 5 valores posibles: nulo, débil, regular, extenso o no aplica. Para cada atributo clave se obtiene un nivel de madurez, aplicando un algoritmo numérico, dando como

definido, 4-administrado o 5-optimizado. Estos niveles de madurez están subdivididos en cuatro, de forma que se obtenga una calificación más exacta. Los procesos de organización y metodología se califican de 1 a 5,

, la organización recibe 2 reportes, uno con los resultados de la evaluación de la UPS y otro con los resultados del proyecto evaluado. El correspondiente

ión como: un resumen ejecutivo, los objetivos de la UPS, los puntos débiles y fuertes, un plan de acción recomendado, etc. El reporte del proyecto contiene: comentarios del proyecto actual detallando lo referente a la organización,

, los niveles de madurez para el proyecto, el plan de acción


Uso de las Bases de Datos de Soporte. es la base de datos con que cuenta para hacer análisis. Con esto se fundamenta el planmejoras, se pueden medir las adaptaciones a la metodología, se puede comparar contra la industria y se pueden establecer objetivos basándose en la competencia. Proceso de Mejora Otra parte importante de la metodología de Bootstrap, es el plan de proceso para obtener el plan de mejora es, Primero evaluar las necesidades de la organización tomando en cuenta las mejoras deseadas e indicadores sobre calidad del producto y servicio, tiempo de desarrollo, costos y riesgos del prodrevisión y análisis de resultados de la evaluación, tomando en cuenta las fortalezas y debilidades detectadas. Después definir las capacidades a mejorar, considerando un período entre 18 y 24 meses. Enseguida, definFinalmente sobre la base de las actividades definidas, modificar la organización y responsabilidades para iniciar el cambio, estableciendo un marco de tiempos para su desarrollo y evaluación.

El Modelo ISO/SPICE

Software Process Improvement and para la Estandarización (ISO) creó el grupo de trabajo WG 10 y le encomendó el desarrollo del estándar internacional de Valuación de Procesos de Software. El grupo de trabajo (Working Group) WG 10, empezó a trabajar en enero de 1993 bajo la dirección de Alec Dorling y Peter Simms, y decidieron crear el proyecto SPICE Software Process Improvement and Capability Determination; la E de SPICE correspondía, originalmente, a "evaluation" y fue cambiado porque en algunos idiomas se traducía equivocadamente. Una de las características sobresalientes de este proyecto de estandarización es que incluyó un periodo de pruebas del estándar de 2 años. Es decir, antes de ser publicado como estándar se había estado ajustando por la práctica. Arquitectura del ModeloEl modelo es tridimensional: lcapacidades (niveles), y la tercera de adecuación o efectividad ( La dimensión PROCESOEstá organizada jerárquicamente de la siguiente manera: CATEGORÍA DE PROCESOS, que agrupan procesos comunes; PROCESOS, que logran propósitos técnicos; PRÁCTICAS BÁSICAS, operaciones que conforman un proceso. Las categorías definidas son: ClienteProveedor, Ingeniería, Proyecto, Organización y Soporte. La dimensión CAPACIDADEstá organizada ordinalmente en niveles de capacidad y se han definido cinco niveles. En la versión 1.0 éstosestos niveles son: Desempeño informal, Planeación y seguimiento bien definido, Cuantitativamente controlado, Mejora continua. Está en etapa de instrumentación una versión 2.0. La tercera dimensión es la El juicio mismo: ¿qué calificación le doy a este proceso en este atributo de capacidad?. Las escalas que se manejan son discretas de tipo: 0 = No adecuado, 1 = Parcialmente adecuado, 2 = Muy Adecuado, 3 = Totalmente Adecuado. Los Elementos de Evaluación Marco de Valor El Modelo ISO/SPICE tiene un marco de valor explícito.proceso: las "mejores prácticas".

CALIDAD DE SOFTWARE

Uso de las Bases de Datos de Soporte. Una de las características principales de Bootstrap es la base de datos con que cuenta para hacer análisis. Con esto se fundamenta el planmejoras, se pueden medir las adaptaciones a la metodología, se puede comparar contra la industria y se pueden establecer objetivos basándose en la competencia.

Otra parte importante de la metodología de Bootstrap, es el plan de mejora que sugiere. El proceso para obtener el plan de mejora es, Primero evaluar las necesidades de la organización tomando en cuenta las mejoras deseadas e indicadores sobre calidad del producto y servicio, tiempo de desarrollo, costos y riesgos del producto y del proyecto. Enseguida hacer una revisión y análisis de resultados de la evaluación, tomando en cuenta las fortalezas y debilidades detectadas. Después definir las capacidades a mejorar, considerando un período entre 18 y 24 meses. Enseguida, definir las prioridades de acuerdo a un análisis de impactos. Finalmente sobre la base de las actividades definidas, modificar la organización y responsabilidades para iniciar el cambio, estableciendo un marco de tiempos para su

mprovement and Capability Determination. La Organización Internacional (ISO) creó el grupo de trabajo WG 10 y le encomendó el desarrollo del

estándar internacional de Valuación de Procesos de Software. El grupo de trabajo (Working Group) WG 10, empezó a trabajar en enero de 1993 bajo la dirección de Alec Dorling y Peter

s, y decidieron crear el proyecto SPICE Software Process Improvement and Capability Determination; la E de SPICE correspondía, originalmente, a "evaluation" y fue cambiado porque en algunos idiomas se traducía equivocadamente. Una de las características

bresalientes de este proyecto de estandarización es que incluyó un periodo de pruebas del estándar de 2 años. Es decir, antes de ser publicado como estándar se había estado ajustando

Arquitectura del Modelo El modelo es tridimensional: la primera dimensión es funcional (procesos

), y la tercera de adecuación o efectividad (calificaciones

PROCESO: Está organizada jerárquicamente de la siguiente manera: CATEGORÍA DE PROCESOS, que

rocesos comunes; PROCESOS, que logran propósitos técnicos; PRÁCTICAS BÁSICAS, operaciones que conforman un proceso. Las categorías definidas son: ClienteProveedor, Ingeniería, Proyecto, Organización y Soporte.

CAPACIDAD: nalmente en niveles de capacidad y se han definido cinco niveles. En la

versión 1.0 éstosestos niveles son: Desempeño informal, Planeación y seguimiento bien definido, Cuantitativamente controlado, Mejora continua. Está en etapa de instrumentación

La tercera dimensión es la CALIFICACIÓN: El juicio mismo: ¿qué calificación le doy a este proceso en este atributo de capacidad?. Las escalas que se manejan son discretas de tipo: 0 = No adecuado, 1 = Parcialmente adecuado,

Totalmente Adecuado.

Los Elementos de Evaluación

El Modelo ISO/SPICE tiene un marco de valor explícito. En la dimensión funcional o de proceso: las "mejores prácticas". En la dimensión de capacidad: los atributos de proceso o

CALIDAD DE SOFTWARE

21

Una de las características principales de Bootstrap es la base de datos con que cuenta para hacer análisis. Con esto se fundamenta el plan de mejoras, se pueden medir las adaptaciones a la metodología, se puede comparar contra la

mejora que sugiere. El proceso para obtener el plan de mejora es, Primero evaluar las necesidades de la organización tomando en cuenta las mejoras deseadas e indicadores sobre calidad del producto y servicio,

ucto y del proyecto. Enseguida hacer una revisión y análisis de resultados de la evaluación, tomando en cuenta las fortalezas y debilidades detectadas. Después definir las capacidades a mejorar, considerando un período

ir las prioridades de acuerdo a un análisis de impactos. Finalmente sobre la base de las actividades definidas, modificar la organización y responsabilidades para iniciar el cambio, estableciendo un marco de tiempos para su

La Organización Internacional (ISO) creó el grupo de trabajo WG 10 y le encomendó el desarrollo del

estándar internacional de Valuación de Procesos de Software. El grupo de trabajo (Working Group) WG 10, empezó a trabajar en enero de 1993 bajo la dirección de Alec Dorling y Peter

s, y decidieron crear el proyecto SPICE Software Process Improvement and Capability Determination; la E de SPICE correspondía, originalmente, a "evaluation" y fue cambiado porque en algunos idiomas se traducía equivocadamente. Una de las características

bresalientes de este proyecto de estandarización es que incluyó un periodo de pruebas del estándar de 2 años. Es decir, antes de ser publicado como estándar se había estado ajustando

procesos), la segunda de calificaciones).

Está organizada jerárquicamente de la siguiente manera: CATEGORÍA DE PROCESOS, que rocesos comunes; PROCESOS, que logran propósitos técnicos; PRÁCTICAS

BÁSICAS, operaciones que conforman un proceso. Las categorías definidas son: Cliente-

nalmente en niveles de capacidad y se han definido cinco niveles. En la versión 1.0 éstosestos niveles son: Desempeño informal, Planeación y seguimiento bien definido, Cuantitativamente controlado, Mejora continua. Está en etapa de instrumentación

El juicio mismo: ¿qué calificación le doy a este proceso en este atributo de capacidad?. Las escalas que se manejan son discretas de tipo: 0 = No adecuado, 1 = Parcialmente adecuado,

En la dimensión funcional o de En la dimensión de capacidad: los atributos de proceso o


prácticas genéricas que incrementarán la capacidad del proceso.componentes más valiosos del estándar internacional. Evidencia La evidencia para la evaluación serán los productos producidos por las prácticas base. Éste es un enfoque de efectividad… catalogado y sus características de calidad definidas. Este es otro elemento filosófico fundamental de ISO/SPICE: no es un modelo nominalista. Recurrencia Por último el elemento recurrencia, para fundamentar un juicio o evaluación vendrá dada por la selección de instancias de proyectos o productos representativas, a juicio del Evaluador, de las capacidades reales del proceso de software. Conceptualmente el mmodelo inductivo en su parte funcional: de característica a producto, de producto a práctica, y de práctica a proceso. En su parte de capacidades es un modelo evolutivo. Es, en general, un modelo realista: va a ver los productos, es descrito en algún manual de calidad o de procesos.

Introducción

El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar laorganizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios:

Puntos De Vista o Ejes

Factor

OPE

RAC

IÓN

DEL

PR

OD

UC

TO

Faci

lidad

de

uso

• Facilidad de facilidad de operación del software.

• Facilidad de comunicación: Atributos del software que proporcionan entradas y salidas fácilmente asimilables.

• Facilidad de aprendizaje: Atributos del software que familiarización inicial del usuario con el software y la transición del modo actual de operación.

• Formación: usuarios apliquen el sistema.

Inte

grid

ad • Control de accesos. Atributos

acceso al software y los datos que maneja.• Facilidad de auditoría:

los accesos al software.• Seguridad:

los programas o los datos.

Corr

ecci

ón

• Completitud: Atributos del software que proporcionan la implementación completa de todas las funciones requeridas.

• Consistencia: Atributos del software que proporcionan uniformidad en las técnicas y notaciones de

• Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto.

CALIDAD DE SOFTWARE

éricas que incrementarán la capacidad del proceso. Este es uno de los componentes más valiosos del estándar internacional.

La evidencia para la evaluación serán los productos producidos por las prácticas base. Éste es un enfoque de efectividad… "por sus frutos los conoceréis…". Cada producto tipo ha sido catalogado y sus características de calidad definidas. Este es otro elemento filosófico fundamental de ISO/SPICE: no es un modelo nominalista.

Por último el elemento recurrencia, para fundamentar un juicio o evaluación vendrá dada por la selección de instancias de proyectos o productos representativas, a juicio del Evaluador, de las capacidades reales del proceso de software. Conceptualmente el modelo ISO/SPICE es un modelo inductivo en su parte funcional: de característica a producto, de producto a práctica, y de práctica a proceso. En su parte de capacidades es un modelo evolutivo. Es, en general, un modelo realista: va a ver los productos, es decir, la efectividad de los procesos no lo que está escrito en algún manual de calidad o de procesos.

EL MODELO MC-CALL

El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto, basándose en once factores de calidad organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios:

Criterios

Facilidad de operación: Atributos del software que determinan la facilidad de operación del software. Facilidad de comunicación: Atributos del software que proporcionan entradas y salidas fácilmente asimilables. Facilidad de aprendizaje: Atributos del software que familiarización inicial del usuario con el software y la transición del modo actual de operación. Formación: El grado en que el software ayuda para permitir que nuevos usuarios apliquen el sistema. Control de accesos. Atributos del software que proporcionan control de acceso al software y los datos que maneja. Facilidad de auditoría: Atributos del software que facilitan la auditoría de los accesos al software. Seguridad: La disponibilidad de mecanismos que controlen o protejan

s programas o los datos. Completitud: Atributos del software que proporcionan la implementación completa de todas las funciones requeridas. Consistencia: Atributos del software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación.Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto.

CALIDAD DE SOFTWARE

22

Este es uno de los

La evidencia para la evaluación serán los productos producidos por las prácticas base. Éste es "por sus frutos los conoceréis…". Cada producto tipo ha sido

catalogado y sus características de calidad definidas. Este es otro elemento filosófico

Por último el elemento recurrencia, para fundamentar un juicio o evaluación vendrá dada por la selección de instancias de proyectos o productos representativas, a juicio del Evaluador, de

odelo ISO/SPICE es un modelo inductivo en su parte funcional: de característica a producto, de producto a práctica, y de práctica a proceso. En su parte de capacidades es un modelo evolutivo. Es, en general, un

ecir, la efectividad de los procesos no lo que está

El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el calidad de un producto, basándose en once factores de calidad

organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios:

operación: Atributos del software que determinan la

Facilidad de comunicación: Atributos del software que proporcionan

Facilidad de aprendizaje: Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición del modo

El grado en que el software ayuda para permitir que nuevos

del software que proporcionan control de

Atributos del software que facilitan la auditoría de

La disponibilidad de mecanismos que controlen o protejan

Completitud: Atributos del software que proporcionan la implementación

Consistencia: Atributos del software que proporcionan uniformidad en diseño e implementación.

Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un


OPE

RAC

IÓN

DEL

PR

OD

UC

TO

Fiab

ilida

d

• Precisión: Atributos del requerido en los cálculos y los resultados.

• Consistencia.• Tolerancia a fallos: Atributos del software que posibilitan la continuidad

del funcionamiento bajo condiciones no usuales.• Modularidad: Atributos del

módulos altamente independientes.• Simplicidad:

funciones de la forma más comprensible posible.• Exactitud:

Efic

ienc

ia • Eficiencia en ejecución: Atributos del software que minimizan el tiempo

de procesamiento.• Eficiencia en almacenamiento: Atributos del software que minimizan el

espacio de almacenamiento necesario.

REV

ISIO

N D

EL P

RO

DU

CTO

Faci

lidad

de

man

teni

mie

nto • Modularidad.

• Simplicidad.• Consistencia.• Concisión: Atributos del software que posibilitan la implementación de

una función con la menor cantidad de códigos posible.• Auto descripción: Atributos del software que proporcionan explicaciones

sobre

Faci

lidad

de

prue

ba

• Modularidad.• Simplicidad.• Auto descripción.• Instrumentación: Atributos del software que posibilitan la observación

del comportamiento del software durante su ejecución para facilitar las mediciones

Flex

ibili

dad

• Auto descripción.• Capacidad de expansión: Atributos del software que posibilitan la

expansión del software en cuanto a capacidades funcionales y datos.• Generalidad: Atributos del software que proporci

funciones implementadas.• Modularidad.

TRAN

SICI

ON

DEL

PR

OD

UC

TO

Reu

sabi

lidad

• Auto descripción.• Generalidad.• Modularidad.• Independencia entre sistema y software: Atributos del software que

determinan su dependencia del entorno operativo.• Independencia del hardware: Atributos del software que determinan su

dependencia del hardware.

Inte

rope

rabi

lidad

• Modularidad.• Compatibilidad de comunicaciones: Atributos del software que posibilitan

el uso de protocolos de comunicación e interfaces • Compatibilidad de datos: Atributos del software que posibilitan el uso

representaciones de datos estándar.• Estandarización en los datos: El uso de estructuras de datos y de tipos

estándar a lo largo de todo el programa.

Port

abili

dad • Auto

• Modularidad.• Independencia entre sistema• Independencia del hardware.

CALIDAD DE SOFTWARE

Precisión: Atributos del software que proporcionan el grado de precisión requerido en los cálculos y los resultados. Consistencia. Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales. Modularidad: Atributos del software que proporcionan una estructura de módulos altamente independientes. Simplicidad: Atributos del software que posibilitan la implementación de funciones de la forma más comprensible posible. Exactitud: La precisión de los cálculos y del control.

Eficiencia en ejecución: Atributos del software que minimizan el tiempo de procesamiento. Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de almacenamiento necesario.

Modularidad. Simplicidad. Consistencia. Concisión: Atributos del software que posibilitan la implementación de una función con la menor cantidad de códigos posible.Auto descripción: Atributos del software que proporcionan explicaciones sobre la implementación de las funciones. Modularidad. Simplicidad. Auto descripción. Instrumentación: Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución para facilitar las mediciones del uso o la identificación de errores. Auto descripción. Capacidad de expansión: Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos.Generalidad: Atributos del software que proporcionan amplitud a las funciones implementadas. Modularidad. Auto descripción. Generalidad. Modularidad. ndependencia entre sistema y software: Atributos del software que

determinan su dependencia del entorno operativo. Independencia del hardware: Atributos del software que determinan su dependencia del hardware. Modularidad. Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos de comunicación e interfaces estándar.Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estándar. Estandarización en los datos: El uso de estructuras de datos y de tipos estándar a lo largo de todo el programa.

Auto descripción. Modularidad. ndependencia entre sistema y software.

Independencia del hardware.

CALIDAD DE SOFTWARE

23

software que proporcionan el grado de precisión

Tolerancia a fallos: Atributos del software que posibilitan la continuidad

software que proporcionan una estructura de

Atributos del software que posibilitan la implementación de

La precisión de los cálculos y del control. Eficiencia en ejecución: Atributos del software que minimizan el tiempo

Eficiencia en almacenamiento: Atributos del software que minimizan el

Concisión: Atributos del software que posibilitan la implementación de una función con la menor cantidad de códigos posible. Auto descripción: Atributos del software que proporcionan explicaciones

Instrumentación: Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución para facilitar las

Capacidad de expansión: Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos.

onan amplitud a las

ndependencia entre sistema y software: Atributos del software que

Independencia del hardware: Atributos del software que determinan su

Compatibilidad de comunicaciones: Atributos del software que posibilitan estándar.

Compatibilidad de datos: Atributos del software que posibilitan el uso

Estandarización en los datos: El uso de estructuras de datos y de tipos


Cómo emplear el modelo de Mc

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

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

calidad establecidos para el proyecto.

Al comienzo del proyecto habrá que especificar los requisitos de calidad del producto software, para lo cual se seleccionarán los aspectos inherentes a la calidad deseada del producto, teniendo que considerarse para ello: ♦ Las características particulares del pr

ciclo de vida que si se espera que sea largo implicará un mayor énfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en desarrollo está destinado a un entorno donde el hardwarportabilidad.

♦ La relación calidad-precio, que puede evaluarse a través del coste de cada factor de calidad frente al beneficio que proporciona. La siguiente tabla muestra la relación calidadpara cada factor considerado:

CorrecciónFiabilidadEficienciaIntegridadFacilidad de usoFacilidad de mantenimientoFacilidad de pruebaFlexibilidadPortabilidadReusabilidadInteroperabilidad

♦ La determinación de las etapas del ciclo de vida donde es necesario evaluar cada factor de

calidad para conocer en cuales se dejan sentir más los efectos de una calidad pobre con respecto a cada uno de los factores.

♦ Las propias interrelaciones entre los factores debido a que algunos factores pueden entrar en conflicto entre sí: por ejemplo, la eficiencia plantea conflictos prácticamente con todos los demás factores de calidad. La interacción entre los diversos factores a reflejada en la tabla I que indica la dependencia entre los factores de McCall.

También habrá que establecer valores deseables para los criterios, para lo cual se emplearán datos históricos, el promedio en la industria, y con ellos se concreotros intermedios o predictivos en cada período de medición durante el desarrollo, así como unos valores mínimos aceptables. La explicación para cualquier selección o decisión deberá ser adecuadamente documentada. En la fase de desarrollo será necesario implementar las métricas elegidas, analizar sus resultados y tomar medidas correctivas cuando los valores obtenidos estén por debajo de los mínimos aceptables. Una vez finalizado el proyecto será necesario contrastar las medidas

CALIDAD DE SOFTWARE

Cómo emplear el modelo de Mc-Call.


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

ienzo del proyecto habrá que especificar los requisitos de calidad del producto software, para lo cual se seleccionarán los aspectos inherentes a la calidad deseada del producto, teniendo que considerarse para ello:

Las características particulares del propio producto que se está diseñando: por ejemplo, su ciclo de vida que si se espera que sea largo implicará un mayor énfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en desarrollo está destinado a un entorno donde el hardware evoluciona rápidamente implicará como requisito su

precio, que puede evaluarse a través del coste de cada factor de calidad frente al beneficio que proporciona. La siguiente tabla muestra la relación calidad

cada factor considerado:

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

La determinación de las etapas del ciclo de vida donde es necesario evaluar cada factor de calidad para conocer en cuales se dejan sentir más los efectos de una calidad pobre con respecto a cada uno de los factores.

propias interrelaciones entre los factores debido a que algunos factores pueden entrar en conflicto entre sí: por ejemplo, la eficiencia plantea conflictos prácticamente con todos los demás factores de calidad. La interacción entre los diversos factores a reflejada en la tabla I que indica la dependencia entre los factores de McCall.

También habrá que establecer valores deseables para los criterios, para lo cual se emplearán datos históricos, el promedio en la industria, y con ellos se concretarán los valores finales y otros intermedios o predictivos en cada período de medición durante el desarrollo, así como unos valores mínimos aceptables.

La explicación para cualquier selección o decisión deberá ser adecuadamente documentada. desarrollo será necesario implementar las métricas elegidas, analizar sus

resultados y tomar medidas correctivas cuando los valores obtenidos estén por debajo de los

Una vez finalizado el proyecto será necesario contrastar las medidas predictivas utilizadas y

CALIDAD DE SOFTWARE

24


Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas. Se selecciona un subconjunto de factores de calidad sobre los que aplicar los requisitos de

ienzo del proyecto habrá que especificar los requisitos de calidad del producto software, para lo cual se seleccionarán los aspectos inherentes a la calidad deseada del

opio producto que se está diseñando: por ejemplo, su ciclo de vida que si se espera que sea largo implicará un mayor énfasis en la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en desarrollo está destinado a un

e evoluciona rápidamente implicará como requisito su

precio, que puede evaluarse a través del coste de cada factor de calidad frente al beneficio que proporciona. La siguiente tabla muestra la relación calidad-precio

La determinación de las etapas del ciclo de vida donde es necesario evaluar cada factor de calidad para conocer en cuales se dejan sentir más los efectos de una calidad pobre con

propias interrelaciones entre los factores debido a que algunos factores pueden entrar en conflicto entre sí: por ejemplo, la eficiencia plantea conflictos prácticamente con todos los demás factores de calidad. La interacción entre los diversos factores a evaluar queda reflejada en la tabla I que indica la dependencia entre los factores de McCall.

También habrá que establecer valores deseables para los criterios, para lo cual se emplearán tarán los valores finales y

otros intermedios o predictivos en cada período de medición durante el desarrollo, así como

La explicación para cualquier selección o decisión deberá ser adecuadamente documentada. desarrollo será necesario implementar las métricas elegidas, analizar sus

resultados y tomar medidas correctivas cuando los valores obtenidos estén por debajo de los

predictivas utilizadas y


comprobar si, en efecto, se pueden tomar como indicadores de los valores finales.

Descripción de los factores Mc

1. Corrección: Hasta qué punto un programa cumple sus especificaciones y satisface los objetivos del usuario. Por ejemplo, si un programa debe ser capaz de sumar dos números y en lugar de sumar los multiplica, es un programa incorrecto. Es quizás el factor más importante, aunque puede no servir de nada sin los demás factores.

2. Fiabilidad: Hasta qué punto se puede confiar en el funcionamiento sin errores del programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25% de los casos el resultado que da no

3. Eficiencia: Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un programa para desempeñar su función. Un programa que suma dos números y necesita 2 MB de memoria para funcionar, o que tarda 2 horas en dareficiente.

4. Integridad: Hasta qué punto se controlan los accesos ilegales a programas o datos. Un programa que permite el acceso de personas no autorizadas a ciertos datos es poco íntegro.

5. Facilidad de uso: El coste y esfuerzo de aprentrada de datos e interpretar la salida del mismo.

6. Facilidad de mantenimiento:que aparecen durante su funcionamiento.

7. Facilidad de prueba:requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de un sistema para poder probar que funciona bien, es un programa difícil de probar.

8. Flexibilidad: El coste de modificación 9. Portabilidad (o Transportabilidad): El coste de transportar o migrar un producto de una

configuración hardware o entorno operativo a otro.10. Facilidad de Reutilización:

del presente sistema a otra aplicación, y con qué esfuerzo.11. Interoperabilidad:

operar conjuntamente con otros sistemas o aplicaciones software externos.

Cada uno de estos factores se descompone, a su vez, en criterios. En el modelo de McCall se definen un total de 23 criterios, con el siguiente significado: 1. Facilidad de operación:

del software. 2. Facilidad de comun

entradas y salidas fácilmente asimilables.3. Facilidad de aprendizaje:

del usuario con el software y la transición desde el modo actual de operación.4. Control de accesos:

software y los datos que maneja5. Facilidad de auditoría:

los accesos al software.6. Eficiencia en ejecución:

procesamiento. 7. Eficiencia en almacenamiento:

almacenamiento necesario.8. Precisión: Atributos del software que proporcionan el grado de precisión requerido en los

cálculos y los resultados.9. Consistencia: Atributos del software que proporcionan uniform

notaciones de diseño e implementación utilizadas.10. Tolerancia a fallos:

funcionamiento bajo condiciones no usuales.

CALIDAD DE SOFTWARE


Descripción de los factores Mc-Call

Hasta qué punto un programa cumple sus especificaciones y satisface los objetivos del usuario. Por ejemplo, si un programa debe ser capaz de sumar dos números y en lugar de sumar los multiplica, es un programa incorrecto. Es quizás el factor más

e, aunque puede no servir de nada sin los demás factores. Hasta qué punto se puede confiar en el funcionamiento sin errores del

programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25% de los casos el resultado que da no es correcto, es poco fiable.

Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un programa para desempeñar su función. Un programa que suma dos números y necesita 2 MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta, es poco

Hasta qué punto se controlan los accesos ilegales a programas o datos. Un programa que permite el acceso de personas no autorizadas a ciertos datos es poco

El coste y esfuerzo de aprender a manejar un producto, preparar la entrada de datos e interpretar la salida del mismo. Facilidad de mantenimiento: El coste de localizar y corregir defectos en un programa que aparecen durante su funcionamiento. Facilidad de prueba: El coste de probar un programa para comprobar que satisface sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de un sistema para poder probar que funciona bien, es un programa difícil de probar.

El coste de modificación del producto cuando cambian sus especificaciones.(o Transportabilidad): El coste de transportar o migrar un producto de una

configuración hardware o entorno operativo a otro. Facilidad de Reutilización: Hasta qué punto se puede transferir un del presente sistema a otra aplicación, y con qué esfuerzo. Interoperabilidad: El coste y esfuerzo necesario para hacer que el software pueda operar conjuntamente con otros sistemas o aplicaciones software externos.

tores se descompone, a su vez, en criterios. En el modelo de McCall se definen un total de 23 criterios, con el siguiente significado:

Facilidad de operación: Atributos del software que determinan la facilidad de operación

Facilidad de comunicación: Atributos del software que proporcionan al usuario entradas y salidas fácilmente asimilables. Facilidad de aprendizaje: Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición desde el modo actual de operación.Control de accesos: Atributos del software que proporcionan control de acceso al software y los datos que maneja. Facilidad de auditoría: Atributos del software que facilitan el registro y la auditoría de los accesos al software. Eficiencia en ejecución: Atributos del software que minimizan el tiempo de

Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de almacenamiento necesario.

Atributos del software que proporcionan el grado de precisión requerido en los cálculos y los resultados.

Atributos del software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación utilizadas. Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales.

CALIDAD DE SOFTWARE

25



Hasta qué punto se puede confiar en el funcionamiento sin errores del

programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25% de

Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un programa para desempeñar su función. Un programa que suma dos números y necesita 2

una respuesta, es poco


ender a manejar un producto, preparar la

El coste de localizar y corregir defectos en un programa

r un programa para comprobar que satisface sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de un sistema para poder probar que funciona bien, es un programa difícil de probar.

del producto cuando cambian sus especificaciones. (o Transportabilidad): El coste de transportar o migrar un producto de una

Hasta qué punto se puede transferir un módulo o programa

El coste y esfuerzo necesario para hacer que el software pueda operar conjuntamente con otros sistemas o aplicaciones software externos.

tores se descompone, a su vez, en criterios. En el modelo de McCall se

Atributos del software que determinan la facilidad de operación

Atributos del software que proporcionan al usuario

Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición desde el modo actual de operación.

Atributos del software que proporcionan control de acceso al

Atributos del software que facilitan el registro y la auditoría de

Atributos del software que minimizan el tiempo de

Atributos del software que minimizan el espacio de

Atributos del software que proporcionan el grado de precisión requerido en los

idad en las técnicas y

Atributos del software que posibilitan la continuidad del


11. Modularidad: Atributos del software que proporcionan una estaltamente independientes.

12. Simplicidad: Atributos del software que posibilitan la implementación de funciones de la forma más comprensible posible.

13. Completitud: Atributos del software que proporcionan la implementación completa de todas las funciones requeridas.

14. Trazabilidad (Rastreabilidad): Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto.

15. Auto descripción: implementación de las funciones.

16. Capacidad de expansión:software en cuanto a capacidades funcionales y datos.

17. Generalidad: Atributos del software que proporcionan amplitud a las funimplementadas.

18. Instrumentación: comportamiento del software durante su ejecución (para facilitar las mediciones del uso o la identificación de errores).

19. Independencia entre sistema y softwareindependencia del entorno operativo.

20. Independencia del hardware:del hardware.

21. Compatibilidad de comunicaciones:protocolos de comunicación e interfaces estándar.

22. Compatibilidad de datos:de datos estándar.

23. Concisión: Atributos del software que posibilitan la implementación de una función con la menor cantidad de código posible.

CALIDAD DE SOFTWARE

Atributos del software que proporcionan una estaltamente independientes.

Atributos del software que posibilitan la implementación de funciones de la forma más comprensible posible.

Atributos del software que proporcionan la implementación completa de as funciones requeridas.

(Rastreabilidad): Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto.

Atributos del software que proporcionan expliimplementación de las funciones. Capacidad de expansión: Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos.

Atributos del software que proporcionan amplitud a las fun

Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución (para facilitar las mediciones del uso o la identificación de errores). Independencia entre sistema y software: Atributos del software que determinan su independencia del entorno operativo. Independencia del hardware: Atributos del software que determinan su independencia

Compatibilidad de comunicaciones: Atributos del software que posibilitan el usprotocolos de comunicación e interfaces estándar. Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones

Atributos del software que posibilitan la implementación de una función con la r cantidad de código posible.

CALIDAD DE SOFTWARE

26

Atributos del software que proporcionan una estructura de módulos

Atributos del software que posibilitan la implementación de funciones de la

Atributos del software que proporcionan la implementación completa de

(Rastreabilidad): Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto.

Atributos del software que proporcionan explicaciones sobre la

Atributos del software que posibilitan la expansión del

Atributos del software que proporcionan amplitud a las funciones

Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución (para facilitar las mediciones del uso o

Atributos del software que determinan su

Atributos del software que determinan su independencia

Atributos del software que posibilitan el uso de

Atributos del software que posibilitan el uso representaciones

Atributos del software que posibilitan la implementación de una función con la



MÉTRICAS DE CALIDAD DE SOFTWARE

Introducción

El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos de de calidad para el software. El estándar

• Funcionalidad. El grado en que el software satisface las necesidades indicadas por los siguientes sub-atributos: idoneidad, corrección, interoperavilidad, conformidad y seguridad.

• Confiabilidad. Cantidad de referido por los siguientes subrecuperación.

• Usabilidad. Grado en que el software es fácil de usar. Viene reflejado por los siguientes sub-atributos: facilidad de comprensión, facilidad de aprendizaje y operatividad.

• Eficiencia. Grado en que el software hace óptimo el uso de los recursos del sistema. Está indicado por los siguientes sub

• Facilidad de mantenimientorealizada. Está indicada por los siguientes subcambio, estabilidad y facilidad de prueba.

• Portabilidad. La facilidad con que el software puede sEstá referido por los siguientes subfacilidad de adaptación al cambio.

Los factores ISO 9126 no necesariamente son utilizados para medidas directas. En cualquier cfacilitan una valiosa base para medidas indirectas y una excelente lista para determinar la calidad de un sistema.

La transición a una visión cuantitativa En las separatas precedentes se estudiaron un conjunto de factores cualitativos para la «medición» de la calidad del software. Intentamos desarrollar medidas exactas de la calidad del software frustradas a veces por la naturaleza subjetiva de la actividad. Cavano y McCall estudian esta situación: La determinación de la calidad es un factor clave encata de vinos, acontecimientos deportivos (por ejemplo, la gimnasia), concursos de talento, etc. En estas situaciones, la calidad se juzga de la manera más fundamental y directa: comparación de objetos unos al predeterminados. El vino puede ser juzgado de acuerdo con su claridad, color, bouquet, sabor, etc. Sin embargo, este tipo de juicio es muy subjetivo; para que tenga algo de valor, debe hacerse por un experto. La subjetividad y la especialización también influyen en la determinación de la calidad del software. Para resolver este problema, se necesita una definición de calidad del software más exacta, así como una manera de obtener medidas cuanti

CALIDAD DE SOFTWARE



ESTÁNDAR ISO 9126

El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos de de calidad ware. El estándar identifica seis atributos clave de calidad:

. El grado en que el software satisface las necesidades indicadas por los atributos: idoneidad, corrección, interoperavilidad, conformidad y

. Cantidad de tiempo que el software está disponible para su uso. Está referido por los siguientes sub-atributos: madurez, tolerancia a fallos y facilidad de

. Grado en que el software es fácil de usar. Viene reflejado por los siguientes butos: facilidad de comprensión, facilidad de aprendizaje y operatividad.

. Grado en que el software hace óptimo el uso de los recursos del sistema. Está indicado por los siguientes sub-atributos: tiempo de uso y recursos utilizados.

mantenimiento. La facilidad con que una modificación puede ser realizada. Está indicada por los siguientes sub-atributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.

La facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes sub-atributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio.

Los factores ISO 9126 no necesariamente son utilizados para medidas directas. En cualquier cfacilitan una valiosa base para medidas indirectas y una excelente lista para determinar la calidad

La transición a una visión cuantitativa

En las separatas precedentes se estudiaron un conjunto de factores cualitativos para la ón» de la calidad del software. Intentamos desarrollar medidas exactas de la calidad

del software frustradas a veces por la naturaleza subjetiva de la actividad. Cavano y McCall

La determinación de la calidad es un factor clave en los acontecimientos diarios: concursos de cata de vinos, acontecimientos deportivos (por ejemplo, la gimnasia), concursos de talento, etc. En estas situaciones, la calidad se juzga de la manera más fundamental y directa: comparación de objetos unos al lado de los otros bajo condiciones idénticas y con conceptos predeterminados. El vino puede ser juzgado de acuerdo con su claridad, color, bouquet, sabor, etc. Sin embargo, este tipo de juicio es muy subjetivo; para que tenga algo de valor,

n experto.

La subjetividad y la especialización también influyen en la determinación de la calidad del software. Para resolver este problema, se necesita una definición de calidad del software más exacta, así como una manera de obtener medidas cuantitativas de la calidad del software para

CALIDAD DE SOFTWARE

27


El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos de de calidad

. El grado en que el software satisface las necesidades indicadas por los atributos: idoneidad, corrección, interoperavilidad, conformidad y

tiempo que el software está disponible para su uso. Está atributos: madurez, tolerancia a fallos y facilidad de

. Grado en que el software es fácil de usar. Viene reflejado por los siguientes butos: facilidad de comprensión, facilidad de aprendizaje y operatividad.

. Grado en que el software hace óptimo el uso de los recursos del sistema. Está atributos: tiempo de uso y recursos utilizados.

. La facilidad con que una modificación puede ser atributos: facilidad de análisis, facilidad de

er llevado de un entorno a otro. atributos: facilidad de instalación, facilidad de ajuste,

Los factores ISO 9126 no necesariamente son utilizados para medidas directas. En cualquier caso facilitan una valiosa base para medidas indirectas y una excelente lista para determinar la calidad

En las separatas precedentes se estudiaron un conjunto de factores cualitativos para la ón» de la calidad del software. Intentamos desarrollar medidas exactas de la calidad

del software frustradas a veces por la naturaleza subjetiva de la actividad. Cavano y McCall

los acontecimientos diarios: concursos de cata de vinos, acontecimientos deportivos (por ejemplo, la gimnasia), concursos de talento, etc. En estas situaciones, la calidad se juzga de la manera más fundamental y directa:

o de los otros bajo condiciones idénticas y con conceptos predeterminados. El vino puede ser juzgado de acuerdo con su claridad, color, bouquet, sabor, etc. Sin embargo, este tipo de juicio es muy subjetivo; para que tenga algo de valor,

La subjetividad y la especialización también influyen en la determinación de la calidad del software. Para resolver este problema, se necesita una definición de calidad del software más

tativas de la calidad del software para


hacer un análisis objetivo.... Como no existe el conocimiento absoluto, no deberíamos esperar poder medir la calidad del software exactamente, ya que cada medición es parcialmente imperfecta. En las siguientes secciones examinamos un conjunaplicarse a la valoración cuantitativa de la calidad del software. En todos los casos, las métricas representan medidas indialguna manifestación de la calidad. El factor que lo complica es la relación exacta entre la variable que se mide y la calidad del software.

Métricas de calidad de software

1. Corrección: Hasta qué punto un programa cumple sus especificaciones y satisface los

objetivos del usuario. Por ejemplo, si un programa debe ser capaz de sumar dos números y en lugar de sumar los multiplica, es un programa incorrecto. Es quizás el factor más importante, aunque puede no servir de nada sin los demás factores.

Número de requerimientos implementados

Corrección = ----------------------------------------------------------------------- Número de requerimientos determinados en el análisis

CALIDAD DE SOFTWARE

vo.... Como no existe el conocimiento absoluto, no deberíamos esperar poder medir la calidad del software exactamente, ya que cada medición es parcialmente

iones examinamos un conjunto de métricas del software que pueden aplicarse a la valoración cuantitativa de la calidad del software. En todos los casos, las métricas representan medidas indirectas; es decir, realmente nunca medimos la calidad sino

manifestación de la calidad. El factor que lo complica es la relación exacta entre la variable que se mide y la calidad del software.

Métricas de calidad de software


e, aunque puede no servir de nada sin los demás factores.

Número de requerimientos implementados -----------------------------------------------------------------------

Número de requerimientos determinados en el análisis

CALIDAD DE SOFTWARE

28

vo.... Como no existe el conocimiento absoluto, no deberíamos esperar poder medir la calidad del software exactamente, ya que cada medición es parcialmente

to de métricas del software que pueden aplicarse a la valoración cuantitativa de la calidad del software. En todos los casos, las

rectas; es decir, realmente nunca medimos la calidad sino manifestación de la calidad. El factor que lo complica es la relación exacta entre la


----------------------------------------------------------------------- Número de requerimientos determinados en el análisis


2. Fiabilidad: Hasta qué punto se puede confiar en el funcionamiento sin errores del

programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25% de los casos el resultado que da no es correcto, es poco fiable.

Fiabilidad = 1

3. Eficiencia: Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un

programa para desempeñar su función. Un programa que suma dos números y necesita 2MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta, es poco eficiente. Para el cálculo de la eficiencia, se debe medir el valor por cada función o módulo según los siguientes parámetros: (ISO 9126)

•••• Uso de Procesador (en porcentaje)

La cantidad de procesador que emplea el módulo durante su ejecución•••• Uso de Memoria (en

La cantidad de memoria que emplea el módulo durante su ejecución•••• Tiempo (en segundos)

La cantidad de segundos que emplea el módulo para efectuar cálculos La eficiencia está dada por las fórmulas:

UP-UM-

T-Promedio = T Se calculará las eficiencias parciales por cada módulo:

EficienciaEficienciaEficiencia

Se calculará la eficiencia final:

n Σ [Eficiencia i=1

Eficiencia = 1 -

4. Integridad: Hasta qué punto se controlan los accesos ilegales a programas o datos. Un

programa que permite el acceso de personas no autorizadas a ciertos datos es poco íntegro.

Integridad = 1

5. Mantenimiento: El durante su funcionamiento.

Mantenimiento = 1

6. Índice de madurez del software:

IMS = [ MT - ( FA + FC + FD ) ] / MT

CALIDAD DE SOFTWARE

qué punto se puede confiar en el funcionamiento sin errores del programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25% de los casos el resultado que da no es correcto, es poco fiable.

Fiabilidad = 1 - (número de errores / número de intentos)

Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un programa para desempeñar su función. Un programa que suma dos números y necesita 2MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta, es poco

l cálculo de la eficiencia, se debe medir el valor por cada función o módulo según los siguientes parámetros: (ISO 9126)

Uso de Procesador (en porcentaje) � UP La cantidad de procesador que emplea el módulo durante su ejecuciónUso de Memoria (en megabytes) � UM La cantidad de memoria que emplea el módulo durante su ejecuciónTiempo (en segundos) � T La cantidad de segundos que emplea el módulo para efectuar cálculos

La eficiencia está dada por las fórmulas:

-Promedio = UP-Disponible / Número de Módulos-Promedio = UM-Disponible / Número de MódulosPromedio = T-Disponible / Número de Módulos

Se calculará las eficiencias parciales por cada módulo:

Eficiencia-UP(i) = UP(i) / UP-Promedio Eficiencia-UM(i) = UM(i) / UM-Promedio Eficiencia-T(i) = T(i) / T-Promedio

Se calculará la eficiencia final:

Σ [Eficiencia-UP(i)+Eficencia-UM(i)+Eficencia-T(i)] / 3

Número de módulos (n)


Integridad = 1-(número de accesos ilegales/número total de accesos)

El coste de localizar y corregir defectos en un programa que aparecen durante su funcionamiento.

Mantenimiento = 1 - 0.1 (número medio de días-hombre por corrección)

Índice de madurez del software:

( FA + FC + FD ) ] / MT

CALIDAD DE SOFTWARE

29

qué punto se puede confiar en el funcionamiento sin errores del programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25% de

e intentos)

Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un programa para desempeñar su función. Un programa que suma dos números y necesita 2MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta, es poco

l cálculo de la eficiencia, se debe medir el valor por cada función o

La cantidad de procesador que emplea el módulo durante su ejecución

La cantidad de memoria que emplea el módulo durante su ejecución

La cantidad de segundos que emplea el módulo para efectuar cálculos

e Módulos Disponible / Número de Módulos


(número de accesos ilegales/número total de accesos)

coste de localizar y corregir defectos en un programa que aparecen

hombre por corrección)


Donde: MT: Número de módulos de la versión actualFC: Número de módulos en la versión actual que han cambiadoFA: Número de módulos en la versión actual que se han añadidoFD: Número de módulos de la versión anterior que se ha borrado en la actualA medida que el IMS se aprpuede emplearse tammantenimiento del software. El tiempo medio para producir una versión de un producto software pueempíricos para el mantenimiento.

7. Flexibilidad: El coste de modificación del producto cuando cambian sus especificaciones.

Flexibilidad = 1

8. Capacidad de Pruebas:

sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de un sistema para poder probar que funciona bien, es un programa difícil de probar.

CP = 1-(número de funciones

9. Portabilidad (o Transportabilidad)

una configuración hardware o entorno operativo a otro.

Portabilidad = 1

10. Reusabilidad: Hasta qué punto se puede transferir un módulo o programa del presente sistema a otra aplicación, y con qué esfuerzo.

Reusabilidad = Σ portabilidad por m

11. Interoperabilidad:

operar conjuntamente con otros sistemas o aplicaciones software externos.

Interoperabilidad = módulos integrados

12. Usabilidad: El coste y esfuerzo de aprender a manejar un producto, preparar la entrada de datos e interpretar la salida del mismo.

Usabilidad = ---------------------------------------------------------------

CALIDAD DE SOFTWARE

de módulos de la versión actual FC: Número de módulos en la versión actual que han cambiado FA: Número de módulos en la versión actual que se han añadido FD: Número de módulos de la versión anterior que se ha borrado en la actualA medida que el IMS se aproxima a 1.0 el producto se empieza a estabilizar. EL IMS puede emplearse también como métrica para la planificación de las activimantenimiento del software. El tiempo medio para producir una versión de un producto software puede correlacionarse con el IMS desarrollándose modeempíricos para el mantenimiento.

El coste de modificación del producto cuando cambian sus especificaciones.

exibilidad = 1 - 0.05 (número medio de días-hombre por cambio)

Capacidad de Pruebas: El coste de probar un programa para comprobar que satisface sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de un sistema para poder probar que funciona bien, es un programa difícil de probar.

(número de funciones probadas/número total de funciones)

(o Transportabilidad): El coste de transportar o migrar un producto de una configuración hardware o entorno operativo a otro.

Portabilidad = 1-(esfuerzo para portar/esfuerzo para implementar)

Hasta qué punto se puede transferir un módulo o programa del presente sistema a otra aplicación, y con qué esfuerzo.

Reusabilidad = Σ portabilidad por módulo / número total de módulos

Interoperabilidad: El coste y esfuerzo necesario para hacer que el soperar conjuntamente con otros sistemas o aplicaciones software externos.

Interoperabilidad = módulos integrados / módulos del software

El coste y esfuerzo de aprender a manejar un producto, preparar la entrada pretar la salida del mismo.

Tiempo medio de aprendizaje por módulo ---------------------------------------------------------------

Tiempo de aprendizaje total / Número de módulos

CALIDAD DE SOFTWARE

30

FD: Número de módulos de la versión anterior que se ha borrado en la actual

oxima a 1.0 el producto se empieza a estabilizar. EL IMS bién como métrica para la planificación de las actividades de

mantenimiento del software. El tiempo medio para producir una versión de un con el IMS desarrollándose modelos

El coste de modificación del producto cuando cambian sus especificaciones.

hombre por cambio)

e de probar un programa para comprobar que satisface sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de un sistema para poder probar que funciona bien, es un programa difícil de probar.

probadas/número total de funciones)

: El coste de transportar o migrar un producto de

(esfuerzo para portar/esfuerzo para implementar)

Hasta qué punto se puede transferir un módulo o programa del presente

ódulo / número total de módulos

El coste y esfuerzo necesario para hacer que el software pueda operar conjuntamente con otros sistemas o aplicaciones software externos.

módulos del software

El coste y esfuerzo de aprender a manejar un producto, preparar la entrada

--------------------------------------------------------------- Tiempo de aprendizaje total / Número de módulos


EJECUCIÓN DEL CONTROL DE

Introducción

El objetivo de las actividades de Control de Calidad es comprobar si un producto posee o no posee una determinada característica de calidad en el grado requerido. Cuando un producto no posee una determinada tanto, se puede decir también que el objetivo del Control de Calidad es identificar defectos en el producto y corregirlos.Se pueden clasificar las actividades de control de calidad en dos cateestáticos y controles dinámicos. Los primeros analizan el objeto sin necesidad de ejecutarlo mientras que los segundos requieren la ejecución del objeto que está siendo probado.

CALIDAD DE SOFTWARE


EJECUCIÓN DEL CONTROL DE CALIDAD DE SOFTWARE

El objetivo de las actividades de Control de Calidad es comprobar si un producto posee o no posee una determinada característica de calidad en el grado requerido. Cuando un producto no posee una determinada característica de calidad se dice que tiene un DEFECTO. Por lo tanto, se puede decir también que el objetivo del Control de Calidad es identificar defectos en el producto y corregirlos. Se pueden clasificar las actividades de control de calidad en dos cateestáticos y controles dinámicos. Los primeros analizan el objeto sin necesidad de ejecutarlo mientras que los segundos requieren la ejecución del objeto que está siendo probado.

CALIDAD DE SOFTWARE

31

CALIDAD DE SOFTWARE

El objetivo de las actividades de Control de Calidad es comprobar si un producto posee o no posee una determinada característica de calidad en el grado requerido. Cuando un producto

característica de calidad se dice que tiene un DEFECTO. Por lo tanto, se puede decir también que el objetivo del Control de Calidad es identificar defectos en

Se pueden clasificar las actividades de control de calidad en dos categorías: controles estáticos y controles dinámicos. Los primeros analizan el objeto sin necesidad de ejecutarlo mientras que los segundos requieren la ejecución del objeto que está siendo probado.


La barrera entre controles estáticos y dinámicos no escontrol dinámico requiere un cierto grado de análisis estático. Además hay algunas técnicas, como la verificación formal y la ejecución simbólica, consideradas como estáticas, que "ejecutan" el código, aunque en un

Controles Estáticos Manuales

Controles estáticos manuales informales Estas actividades las realizan los propios autores de los objetos a comprobar, o personas de su misma categoría y ocupación. Comprobación de escritorio Consiste en examinar a mano e individualmente el objeto que se acaba de desarrollar. Es el método más tradicional para analizar un programa. Se debe aplicar a los requisitos, especificaciones de diseño y código según se van desconcienzudo para que sea efectivo. Es más efectivo si se hace intercambiando el objeto a examinar con otro compañero. Revisión por pares o iguales Consiste en la revisión del código de un programador por otSe puede poner en práctica creando un panel que se encarga de revisar periódicamente muestras de código.

Controles estáticos manuales disciplinados Las revisiones y auditorías son la evolución natural de la Comprobación dediferencia de aquélla pasan a ser técnicas de grupo. Su misión principal es conseguir que la responsabilidad del control de calidad no recaiga sólo sobre el propio desarrollador. Auditorias Una auditoría consiste en realizar una

- El grado de cumplimiento y la adecuación de los procedimientos, instrucciones, especificaciones, códigos, estándares u otros requisitos de tipo contractual establecidos y aplicables. - La efectividad y adecuación de la imple Se pueden considerar tres

1.- Auditoría del producto:producto con las características requeridas. Las auditorías del producto software más comunes son la a

2.- Auditoría del proceso:gestión, y evaluar su completitud y efectividad, determinando dónde se puede mejorar. En el desarrollo de software se suelen realizarproceso:

- Auditorías de proyecto:

CALIDAD DE SOFTWARE

La barrera entre controles estáticos y dinámicos no es totalmente estricta. Cualquier forma de control dinámico requiere un cierto grado de análisis estático. Además hay algunas técnicas, como la verificación formal y la ejecución simbólica, consideradas como estáticas, que "ejecutan" el código, aunque en un entorno no real.

CONTROLES ESTÁTICOS

Controles Estáticos Manuales

Controles estáticos manuales informales

Estas actividades las realizan los propios autores de los objetos a comprobar, o personas de su misma categoría y ocupación.

escritorio (desk checking):

Consiste en examinar a mano e individualmente el objeto que se acaba de desarrollar. Es el método más tradicional para analizar un programa. Se debe aplicar a los requisitos, especificaciones de diseño y código según se van desarrollando. Debe ser cuidadoso y concienzudo para que sea efectivo. Es más efectivo si se hace intercambiando el objeto a examinar con otro compañero.

Revisión por pares o iguales (peer review):

Consiste en la revisión del código de un programador por otros programadores (sus pares).Se puede poner en práctica creando un panel que se encarga de revisar periódicamente

Controles estáticos manuales disciplinados

Las revisiones y auditorías son la evolución natural de la Comprobación dediferencia de aquélla pasan a ser técnicas de grupo. Su misión principal es conseguir que la responsabilidad del control de calidad no recaiga sólo sobre el propio desarrollador.

Una auditoría consiste en realizar una investigación para determinar:

El grado de cumplimiento y la adecuación de los procedimientos, instrucciones, especificaciones, códigos, estándares u otros requisitos de tipo contractual establecidos

La efectividad y adecuación de la implementación realizada.

Se pueden considerar tres tipos de auditorías:

Auditoría del producto: El objetivo es cuantificar el grado de conformidad del producto con las características requeridas. Las auditorías del producto software más comunes son la auditoría Funcional y la auditoría Física.

Auditoría del proceso: El objetivo es evaluar el proceso de desarrollo o de gestión, y evaluar su completitud y efectividad, determinando dónde se puede mejorar. En el desarrollo de software se suelen realizar dos tipos de auditorías del

Auditorías de proyecto: cuyo objetivo es evaluar la productividad y

CALIDAD DE SOFTWARE

32

totalmente estricta. Cualquier forma de control dinámico requiere un cierto grado de análisis estático. Además hay algunas técnicas, como la verificación formal y la ejecución simbólica, consideradas como estáticas, que

Estas actividades las realizan los propios autores de los objetos a comprobar, o personas de

Consiste en examinar a mano e individualmente el objeto que se acaba de desarrollar. Es el método más tradicional para analizar un programa. Se debe aplicar a los requisitos,

arrollando. Debe ser cuidadoso y concienzudo para que sea efectivo. Es más efectivo si se hace intercambiando el objeto a

ros programadores (sus pares). Se puede poner en práctica creando un panel que se encarga de revisar periódicamente

Las revisiones y auditorías son la evolución natural de la Comprobación de Escritorio, pero a diferencia de aquélla pasan a ser técnicas de grupo. Su misión principal es conseguir que la responsabilidad del control de calidad no recaiga sólo sobre el propio desarrollador.

El grado de cumplimiento y la adecuación de los procedimientos, instrucciones, especificaciones, códigos, estándares u otros requisitos de tipo contractual establecidos

El objetivo es cuantificar el grado de conformidad del producto con las características requeridas. Las auditorías del producto software más

El objetivo es evaluar el proceso de desarrollo o de gestión, y evaluar su completitud y efectividad, determinando dónde se puede

dos tipos de auditorías del

cuyo objetivo es evaluar la productividad y


eficacia del equipo que trabaja en un proyecto así como la efectividad de los métodos y herramientas utilizados. - Auditorías de gestión de efectividad de las prácticas de gestión realizadas y la organización del proyecto.

3.- Auditoría del sistema de calidad:efectividad del propio sistema de calidad establecido.

El procedimiento habitual para realizar una auditoría consta de los siguientes pasos: 1. Planificación: Consiste en definir los objetivos de la auditoría y su alcance. En esta etapa se elabora un Plan de Auditoría, que debería dar respuesta a cuestionesiguientes:

- ¿Por qué se realiza la auditoría? Puede ser una auditoría de rutina o puede realizarse

para resolver problemas concretos.- ¿Para qué se realiza? para mejorar, para conseguir una certificación,... ¿Cuál

es el producto que- ¿Qué resultados se esperan de la auditoría? En principio, una auditoría debería

identificar situaciones problemáticas, tales como desviaciones del estado actual con respecto al estado deseado, y sugerir posibles soluciones o mejoras.

¿Cómo y dónde se van a utilizar los resultados de la auditoría?- ¿Quiénes son los responsables de llevarla a cabo?

¿De qué forma se va a llevar a cabo? Incluyendo una especificación de los datos que se van a recoger y de qué forma se van a recoger.¿Cuándo se va a realizar?

2. Llevar a cabo la investigación. Por lo general la auditoría se inicia con una reunión de apertura de la investigación, y se lleva a cabo mediante entrevistas y revisiones en las que se recopilan datos. 3. Analizar los datos recogidos. Por lo general el equipo de auditores debe hacer frente a cantidades ingentes de datos, de entre los cuales resulta complicado seleccionar los datos relevantes, por lo que se suelen utilizar técnicas de análisis estadístico. A continuación se realiza una evaluación en paralelo de los resultados por un grupo de evaluadores, se comparan las conclusiones obtenidas y se estudian las causas de las desviaciones significativas. 4. Sugerir soluciones a los problemas encontrados y posibles mejoras. 5. Elaborar y presentar un informe de resultados.

CALIDAD DE SOFTWARE

eficacia del equipo que trabaja en un proyecto así como la efectividad de los métodos y herramientas utilizados.

Auditorías de gestión de proyecto: cuyo objetivo es evaluar la efectividad de las prácticas de gestión realizadas y la organización del proyecto.

Auditoría del sistema de calidad: El objetivo es evaluar la completitud y efectividad del propio sistema de calidad establecido.

habitual para realizar una auditoría consta de los siguientes pasos:

1. Planificación: Consiste en definir los objetivos de la auditoría y su alcance. En esta etapa se elabora un Plan de Auditoría, que debería dar respuesta a cuestione

¿Por qué se realiza la auditoría? Puede ser una auditoría de rutina o puede realizarse para resolver problemas concretos.

¿Para qué se realiza? para mejorar, para conseguir una certificación,... ¿Cuál es el producto que va a ser auditado? ¿Qué resultados se esperan de la auditoría? En principio, una auditoría debería identificar situaciones problemáticas, tales como desviaciones del estado actual con respecto al estado deseado, y sugerir posibles soluciones o mejoras.

¿Cómo y dónde se van a utilizar los resultados de la auditoría? ¿Quiénes son los responsables de llevarla a cabo? ¿De qué forma se va a llevar a cabo? Incluyendo una especificación de los datos que se van a recoger y de qué forma se van a recoger. ¿Cuándo se va a realizar?

Llevar a cabo la investigación. Por lo general la auditoría se inicia con una reunión de apertura de la investigación, y se lleva a cabo mediante entrevistas y revisiones en las que se

ecogidos. Por lo general el equipo de auditores debe hacer frente a cantidades ingentes de datos, de entre los cuales resulta complicado seleccionar los datos relevantes, por lo que se suelen utilizar técnicas de análisis estadístico. A continuación se

liza una evaluación en paralelo de los resultados por un grupo de evaluadores, se comparan las conclusiones obtenidas y se estudian las causas de las desviaciones

4. Sugerir soluciones a los problemas encontrados y posibles mejoras.

aborar y presentar un informe de resultados.

CALIDAD DE SOFTWARE

33

eficacia del equipo que trabaja en un proyecto así como la efectividad de los

cuyo objetivo es evaluar la efectividad de las prácticas de gestión realizadas y la organización del

El objetivo es evaluar la completitud y

habitual para realizar una auditoría consta de los siguientes pasos:

1. Planificación: Consiste en definir los objetivos de la auditoría y su alcance. En esta etapa se elabora un Plan de Auditoría, que debería dar respuesta a cuestiones del tipo de las

¿Por qué se realiza la auditoría? Puede ser una auditoría de rutina o puede realizarse

¿Para qué se realiza? para mejorar, para conseguir una certificación,... ¿Cuál

¿Qué resultados se esperan de la auditoría? En principio, una auditoría debería identificar situaciones problemáticas, tales como desviaciones del estado actual con respecto al estado deseado, y sugerir posibles soluciones o mejoras.

¿De qué forma se va a llevar a cabo? Incluyendo una especificación de los datos que

Llevar a cabo la investigación. Por lo general la auditoría se inicia con una reunión de apertura de la investigación, y se lleva a cabo mediante entrevistas y revisiones en las que se

ecogidos. Por lo general el equipo de auditores debe hacer frente a cantidades ingentes de datos, de entre los cuales resulta complicado seleccionar los datos relevantes, por lo que se suelen utilizar técnicas de análisis estadístico. A continuación se

liza una evaluación en paralelo de los resultados por un grupo de evaluadores, se comparan las conclusiones obtenidas y se estudian las causas de las desviaciones


Revisiones Se puede definir una revisión como una reunión formal en la que se presenta el estado actual de los resultados de un proyecto a un usuario, cliente u otro tipo de persona interesada, y se realiza un análisis estructurado de los mismos.Uno de los objetivos fundamentales de las revisiones técnicas es ofrecer a los gestores información fiable acerca de los aspectos técnicos del proceso de desarrollo de software, de la misma forma que les llega informtrabajo, para que con esta información puedan tomar decisiones adecuadas para dirigir con éxito el proyecto. Con las revisiones se consigue que el peso de la evaluación técnica no recaiga sobre las mismas personas involucradas en la producción del software, que por la posición que ocupan no pueden ser totalmente objetivas, sino en otras personas técnicamente competentes y objetivas. Las revisiones son, hoy en día, el único método de control de calidadiniciales del desarrollo a la hora de identificar desviaciones con respecto a las especificaciones de calidad. Las revisiones redundan en una mejora directa de la calidad del objeto que se examina y provocan, indirectamente, una mejoracomunicación entre los miembros del equipo de desarrollo. Al mismo tiempo facilitan el control del coste y el tiempo. Las diferencias más importantes entre las revisiones y las auditorías son las si

- Las revisiones se llevan a cabo desde las primeras fases del desarrollo, mientras que las auditorías se llevan a cabo en las fases finales. - El objetivo de las revisiones es detectar defectos, mientras que el objetivo de las auditorías es certificar conformidad e identificar desviaciones.

Tipos de revisiones Hay dos tipos fundamentales de revisiones: las inspecciones y los entre ellos está en la forma en que se desarrolla la reunión de revisión.

- Inspecciones: En las que los participantes van leyendo el documento, paso a paso, guiados por el autor del mismo, y comprobando en cada paso el cumplimiento de los criterios de una lista de comprobación. - Walkthrough (visita guiada): En las que se demuestra la funciomediante la simulación de su funcionamiento con casos de prueba y ejemplos. Se introducen al objeto los casos de prueba y se van registrando los resultados intermedios.

Aunque estos son los tipos ideales, en la vida real hadesde las revisiones sin disciplina alguna hasta cualquier tipo de mezcla entre inspecciones y walkthrough. Otras diferencias esenciales entre inspecciones y walkthrough son las siguientes:

CALIDAD DE SOFTWARE

Se puede definir una revisión como una reunión formal en la que se presenta el estado actual de los resultados de un proyecto a un usuario, cliente u otro tipo de persona interesada, y se

un análisis estructurado de los mismos. Uno de los objetivos fundamentales de las revisiones técnicas es ofrecer a los gestores información fiable acerca de los aspectos técnicos del proceso de desarrollo de software, de la misma forma que les llega información fiable acerca de los costes y la programación del trabajo, para que con esta información puedan tomar decisiones adecuadas para dirigir con

Con las revisiones se consigue que el peso de la evaluación técnica no recaiga sobre las ismas personas involucradas en la producción del software, que por la posición que ocupan

no pueden ser totalmente objetivas, sino en otras personas técnicamente competentes y

Las revisiones son, hoy en día, el único método de control de calidadiniciales del desarrollo a la hora de identificar desviaciones con respecto a las especificaciones

Las revisiones redundan en una mejora directa de la calidad del objeto que se examina y provocan, indirectamente, una mejora de la calidad del proceso de desarrollo, al facilitar la comunicación entre los miembros del equipo de desarrollo. Al mismo tiempo facilitan el control

Las diferencias más importantes entre las revisiones y las auditorías son las si

Las revisiones se llevan a cabo desde las primeras fases del desarrollo, mientras que las auditorías se llevan a cabo en las fases finales.

El objetivo de las revisiones es detectar defectos, mientras que el objetivo de las certificar conformidad e identificar desviaciones.

Hay dos tipos fundamentales de revisiones: las inspecciones y los walkthrough.entre ellos está en la forma en que se desarrolla la reunión de revisión.

En las que los participantes van leyendo el documento, paso a paso, guiados por el autor del mismo, y comprobando en cada paso el cumplimiento de los criterios de una lista de comprobación.

Walkthrough (visita guiada): En las que se demuestra la funcionalidad del objeto revisado mediante la simulación de su funcionamiento con casos de prueba y ejemplos. Se introducen al objeto los casos de prueba y se van registrando los resultados intermedios.

Aunque estos son los tipos ideales, en la vida real hay otras muchas variantes intermedias, desde las revisiones sin disciplina alguna hasta cualquier tipo de mezcla entre inspecciones y

Otras diferencias esenciales entre inspecciones y walkthrough son las siguientes:

CALIDAD DE SOFTWARE

34

Se puede definir una revisión como una reunión formal en la que se presenta el estado actual de los resultados de un proyecto a un usuario, cliente u otro tipo de persona interesada, y se

Uno de los objetivos fundamentales de las revisiones técnicas es ofrecer a los gestores información fiable acerca de los aspectos técnicos del proceso de desarrollo de software, de la

ación fiable acerca de los costes y la programación del trabajo, para que con esta información puedan tomar decisiones adecuadas para dirigir con

Con las revisiones se consigue que el peso de la evaluación técnica no recaiga sobre las ismas personas involucradas en la producción del software, que por la posición que ocupan

no pueden ser totalmente objetivas, sino en otras personas técnicamente competentes y

Las revisiones son, hoy en día, el único método de control de calidad eficaz en las fases iniciales del desarrollo a la hora de identificar desviaciones con respecto a las especificaciones

Las revisiones redundan en una mejora directa de la calidad del objeto que se examina y de la calidad del proceso de desarrollo, al facilitar la

comunicación entre los miembros del equipo de desarrollo. Al mismo tiempo facilitan el control

Las diferencias más importantes entre las revisiones y las auditorías son las siguientes:

Las revisiones se llevan a cabo desde las primeras fases del desarrollo, mientras que las

El objetivo de las revisiones es detectar defectos, mientras que el objetivo de las

walkthrough. La diferencia

En las que los participantes van leyendo el documento, paso a paso, guiados por el autor del mismo, y comprobando en cada paso el cumplimiento de los

nalidad del objeto revisado mediante la simulación de su funcionamiento con casos de prueba y ejemplos. Se introducen al objeto los casos de prueba y se van registrando los resultados intermedios.

y otras muchas variantes intermedias,

desde las revisiones sin disciplina alguna hasta cualquier tipo de mezcla entre inspecciones y

Otras diferencias esenciales entre inspecciones y walkthrough son las siguientes:


- Los walkthrough están plamientras que las inspecciones están planteadas como una medida de ayuda al gestor.En los walkthrough el objetivo fundamental es incrementar el entendimiento, comprender mejor el objeto, mientras que en ladefectos. - En las inspecciones el proceso está guiado por la lista de comprobación, y en los walkthrough está guiado por la estructura del producto revisado.

- Las inspecciones se planifican y procesan de una manera mucho más formal que los walkthrough. Se usan para asegurar la satisfacción de los criterios de salida establecidos entre diferentes etapas del desarrollo (revisiones de fase).

La siguiente tabla resume algunas diferencias adicionales entre ellas: Propiedades 1. Requiere entrenamiento formal del moderador 2. Hay unos roles definidos para los participantes 3. Quién guía la revisión

4. Se usan listas de comprobación 5. Se usan distribuciones por tipo de los errores a buscar 6. Hay un seguimiento para controlar que la corrección es correcta 7. Se puede mejorar la eficiencia de la revisión analizando los resultados Fases en una Inspección: 1. Planificación: La preparación comienza con la selección de los participantes. Debe designarse un coordinador o moderador; un secretario; un presentador, de entre los productores del objeto que se revisa; y otros revisores, que pueden ser desarrolladores, representantes de los usuarios, revisores externos; y posiblemente otros.El coordinador es responsable de la planificación de la inspección, de moderar la reunión (mantener el orden, mantener el foco de la revisión, asegurar que se cubren todos los aspectos necesarios), de preparar el informe final y de realizar el seguimiento y evaluación de las acciones pendientes. El secretario es responsable de anotar los elementos de interés (defectos y anomalías descubiertas, acciones pendientes) y ayudar al coordinador en la prepafinal. En la planificación es también necesario determinar:

- Los objetivos de la inspección- Los criterios de finalización de la inspección- El lugar y la fecha para la inspección- La disponibilidad de todos los participantes- La agenda de la reunión

2. Orientación inicial:inspección propiamente dicha, cuando se trata de examinar por primera vez un objeto, para dar a los participantes en la revisión una idea del objet

CALIDAD DE SOFTWARE

Los walkthrough están planteados como una medida de ayuda al desarrollador, mientras que las inspecciones están planteadas como una medida de ayuda al gestor.En los walkthrough el objetivo fundamental es incrementar el entendimiento, comprender mejor el objeto, mientras que en las inspecciones el objetivo es detectar

En las inspecciones el proceso está guiado por la lista de comprobación, y en los walkthrough está guiado por la estructura del producto revisado.

Las inspecciones se planifican y procesan de una manera mucho más formal que los walkthrough. Se usan para asegurar la satisfacción de los criterios de salida establecidos entre diferentes etapas del desarrollo (revisiones de fase).

esume algunas diferencias adicionales entre ellas:

Inspección

1. Requiere entrenamiento formal del moderador SI

2. Hay unos roles definidos para los participantes SI

El moderador

4. Se usan listas de comprobación SI 5. Se usan distribuciones por tipo de los errores a buscar SI

6. Hay un seguimiento para controlar que la corrección es SI

eficiencia de la revisión analizando los SI

Fases en una Inspección:

La preparación comienza con la selección de los participantes. Debe designarse un coordinador o moderador; un secretario; un presentador, de entre los productores del objeto que se revisa; y otros revisores, que pueden ser desarrolladores,

de los usuarios, revisores externos; y posiblemente otros. El coordinador es responsable de la planificación de la inspección, de moderar la reunión (mantener el orden, mantener el foco de la revisión, asegurar que se cubren todos los

de preparar el informe final y de realizar el seguimiento y evaluación de

El secretario es responsable de anotar los elementos de interés (defectos y anomalías descubiertas, acciones pendientes) y ayudar al coordinador en la prepa

En la planificación es también necesario determinar: Los objetivos de la inspección Los criterios de finalización de la inspección El lugar y la fecha para la inspección La disponibilidad de todos los participantes

enda de la reunión

2. Orientación inicial: Es recomendable realizar una reunión de orientación, previa a la inspección propiamente dicha, cuando se trata de examinar por primera vez un objeto, para dar a los participantes en la revisión una idea del objeto que van a revisar.

CALIDAD DE SOFTWARE

35

nteados como una medida de ayuda al desarrollador, mientras que las inspecciones están planteadas como una medida de ayuda al gestor. En los walkthrough el objetivo fundamental es incrementar el entendimiento,

s inspecciones el objetivo es detectar

En las inspecciones el proceso está guiado por la lista de comprobación, y en los

Las inspecciones se planifican y procesan de una manera mucho más formal que los walkthrough. Se usan para asegurar la satisfacción de los criterios de salida establecidos entre diferentes etapas del desarrollo (revisiones de fase).

Inspección Walkthrough

NO NO

El moderador El propietario del producto revisado NO NO NO

NO

La preparación comienza con la selección de los participantes. Debe designarse un coordinador o moderador; un secretario; un presentador, de entre los productores del objeto que se revisa; y otros revisores, que pueden ser desarrolladores,

El coordinador es responsable de la planificación de la inspección, de moderar la reunión (mantener el orden, mantener el foco de la revisión, asegurar que se cubren todos los

de preparar el informe final y de realizar el seguimiento y evaluación de

El secretario es responsable de anotar los elementos de interés (defectos y anomalías descubiertas, acciones pendientes) y ayudar al coordinador en la preparación del informe

Es recomendable realizar una reunión de orientación, previa a la inspección propiamente dicha, cuando se trata de examinar por primera vez un objeto, para

o que van a revisar.


3. Preparación individual:debe hacer llegar a cada revisor una copia de la documentación asociada al objeto que se va a revisar, junto con una lista de comprobacionesdefectos que se deben intentar localizar. Una lista de comprobaciones contiene una serie de preguntas, y se supone que al intentar dar respuesta a estas preguntas saldrán a la luz los problemas que puedan existir. Cadpregunta o defecto detectado. 4. Reunión de inspección:va guiando al resto a través del mismo para comprobar cada uno de los puntocomprobación. Hay varias formas de guiar la reunión:

- Punto por punto de la lista de comprobación, revisando todo el producto para cada uno de ellos. - Componente a componente del producto, revisando todos los puntos de la lista de comprobación para cada componente.- Por grupos de puntos dentro de la lista de comprobación, revisando todo el producto para cada grupo.- Cualquier otra solución intermedia

Los defectos que se detecten durante este proceso se añaden a una lista de pendientes. Hay que tener en cuenta que el objetivo de una inspección es descubrir defectos, no corregirlos. Por otro lado, los revisores deben restringirse a los hechos y ser constructivos. Es misión del moderador asegurarse de que esto se cumpl Al final de la reunión de inspección, los participantes valoran los resultados de la inspección y se completa un informe. Al finalizar la reunión se pueden producir las siguientes situaciones:

- Se cierra la inspección sin que se hayan encontrado defe- Se cerrará la inspección después de que los defectos encontrados se hayan eliminado en la fase de seguimiento.- No se cierra la inspección porque se encontraron defectos importantes, y será necesario realizar una nueva inspección.

5. Seguimiento: Durante esta fase, el autor del objeto revisado se encarga de corregir los defectos encontrados y generar un informe en el que se especifican las acciones correctivas realizadas para eliminar los distintos defectos. 6. Evaluación: Es la última fase y defectos y si han surgido nuevos problemas durante el proceso de corrección. El moderador se encarga de realizar la evaluación y enviar un informe a la dirección una vez finalizada. Documentos generados en una inspección Algunos de los informes o documentos que pueden generarse como resultado de una inspección son los siguientes:

- Informe resumen de la inspección:

(una página - Qué se ha revisado- Quién lo ha revisado- Cuál fue la conclusión

CALIDAD DE SOFTWARE

3. Preparación individual: Con suficiente tiempo antes de la realización de la inspección, se debe hacer llegar a cada revisor una copia de la documentación asociada al objeto que se va a revisar, junto con una lista de comprobaciones o "checkiist" enumerando los posibles defectos que se deben intentar localizar. Una lista de comprobaciones contiene una serie de preguntas, y se supone que al intentar dar respuesta a estas preguntas saldrán a la luz los problemas que puedan existir. Cada revisor debe completar la lista y anotar cualquier tipo de pregunta o defecto detectado.

4. Reunión de inspección: Durante la reunión, el presentador o autor del objeto revisado va guiando al resto a través del mismo para comprobar cada uno de los puntocomprobación. Hay varias formas de guiar la reunión:

Punto por punto de la lista de comprobación, revisando todo el producto para cada

Componente a componente del producto, revisando todos los puntos de la lista de comprobación para cada componente.

Por grupos de puntos dentro de la lista de comprobación, revisando todo el producto para cada grupo.

Cualquier otra solución intermedia

Los defectos que se detecten durante este proceso se añaden a una lista de

Hay que tener en cuenta que el objetivo de una inspección es descubrir defectos, no corregirlos. Por otro lado, los revisores deben restringirse a los hechos y ser constructivos. Es misión del moderador asegurarse de que esto se cumple.

Al final de la reunión de inspección, los participantes valoran los resultados de la inspección y se completa un informe. Al finalizar la reunión se pueden producir las siguientes situaciones:

Se cierra la inspección sin que se hayan encontrado defectos. Se cerrará la inspección después de que los defectos encontrados se hayan

en la fase de seguimiento. No se cierra la inspección porque se encontraron defectos importantes, y será

necesario realizar una nueva inspección.

Durante esta fase, el autor del objeto revisado se encarga de corregir los defectos encontrados y generar un informe en el que se especifican las acciones correctivas realizadas para eliminar los distintos defectos.

Es la última fase y en ella se trata de determinar si se han corregido todos los defectos y si han surgido nuevos problemas durante el proceso de corrección. El moderador se encarga de realizar la evaluación y enviar un informe a la dirección una vez finalizada.

generados en una inspección

Algunos de los informes o documentos que pueden generarse como resultado de una inspección son los siguientes:

Informe resumen de la inspección: Conclusiones breves de la inspección o dos) para la dirección:

Qué se ha revisado Quién lo ha revisado Cuál fue la conclusión

CALIDAD DE SOFTWARE

36

Con suficiente tiempo antes de la realización de la inspección, se debe hacer llegar a cada revisor una copia de la documentación asociada al objeto que se va

o "checkiist" enumerando los posibles defectos que se deben intentar localizar. Una lista de comprobaciones contiene una serie de preguntas, y se supone que al intentar dar respuesta a estas preguntas saldrán a la luz los

a revisor debe completar la lista y anotar cualquier tipo de

Durante la reunión, el presentador o autor del objeto revisado va guiando al resto a través del mismo para comprobar cada uno de los puntos de la lista de

Punto por punto de la lista de comprobación, revisando todo el producto para cada

Componente a componente del producto, revisando todos los puntos de la lista de

Por grupos de puntos dentro de la lista de comprobación, revisando todo el producto

Los defectos que se detecten durante este proceso se añaden a una lista de acciones

Hay que tener en cuenta que el objetivo de una inspección es descubrir defectos, no corregirlos. Por otro lado, los revisores deben restringirse a los hechos y ser constructivos. Es

Al final de la reunión de inspección, los participantes valoran los resultados de la inspección y se completa un informe. Al finalizar la reunión se pueden producir las siguientes situaciones:

Se cerrará la inspección después de que los defectos encontrados se hayan

No se cierra la inspección porque se encontraron defectos importantes, y será

Durante esta fase, el autor del objeto revisado se encarga de corregir los defectos encontrados y generar un informe en el que se especifican las acciones correctivas

en ella se trata de determinar si se han corregido todos los defectos y si han surgido nuevos problemas durante el proceso de corrección. El moderador se encarga de realizar la evaluación y enviar un informe a la dirección una vez finalizada.

Algunos de los informes o documentos que pueden generarse como resultado de una

Conclusiones breves de la inspección


- Lista de acciones pendientes:

revisado explicando qué es lo que está mal y, si puede ser, cómo corregirlo. Necesita ser claro, pero no muytransitorio. datos y para que no de inspección.

- Informe de asuntos relacionados: luz durante la inspección pero no están relacionados directamente con el objeto revisado, para que sean notificados a la persona responsable.

- Informe del proceso de inspección:de inspección en sí mismo.

- Informe final:

Fases en un Walkthrough:

CALIDAD DE SOFTWARE

Lista de acciones pendientes: Es un informe para los autores del producto revisado explicando qué es lo que está mal y, si puede ser, cómo corregirlo. Necesita ser claro, pero no muy elaborado. Es un documento técnico y

No debe llegar a la dirección, para no aburrirlos con tantos datos y para que no puedan usar esta información en perjuicio del proceso de inspección. Informe de asuntos relacionados: Para registrar problemas que salen a la

durante la inspección pero no están relacionados directamente con el revisado, para que sean notificados a la persona responsable.

Informe del proceso de inspección: Cuando algo ha salido mal en el proceso spección en sí mismo.

Informe final: Para informar a la dirección del cierre de la inspección.

Fases en un Walkthrough:

CALIDAD DE SOFTWARE

37

Es un informe para los autores del producto revisado explicando qué es lo que está mal y, si puede ser, cómo corregirlo.

elaborado. Es un documento técnico y No debe llegar a la dirección, para no aburrirlos con tantos

puedan usar esta información en perjuicio del proceso

roblemas que salen a la durante la inspección pero no están relacionados directamente con el

revisado, para que sean notificados a la persona responsable. Cuando algo ha salido mal en el proceso

Para informar a la dirección del cierre de la inspección.


El proceso para realizar un walkthrough es mucho más sencillo y consta de tan sólo tres fases:

1. Planificación: de que no es necesario asignar roles específicos a los participantes, a excepción del presentador, que es quien organiza el walkthrough y guía la reunión. 2. Preparación individual:este caso no se les entregará una lista de comprobación. 3. Reunión de walkthrough

La siguiente tabla resume las fases de inspecciones y walkthrough e indica los objetivos que se persiguen en cada una de ellas:

Inspección

Etapas

Objetivo

1. Orientación

Educación (grupo)

2. Preparación individual

Educación (individual)

3. Reunión

Encontrar errores (grupo)

4. Seguimiento

Arreglar problemas

5. Evaluación

Asegurar que todos los problemas se han resuelto correctamente

Formalidad en las revisiones Se puede diferenciar también entre las revisiones formales e informales. Se dice que una revisión es formal cuando:

- Es un evento público- Se informa por escrito de los resultados- Todos los participantes son responsables de la calidad de la revisión.

La ventaja de realizar revisiones formales es que los informes que se generan sirven como hitos para el proyecto, y el hecho de ser algo público promueve una mejor preparación por parte de los participantes. Por contra, la formalidad hace que este tipo de reuniones sean un tanto impersonales.Para evitar que los participantes se sientan intimidados por el ambiente impersonal y expresen libremente sus opiniones se pueden utilizar técnicas como el consiste en ir pasando el tumo de uno a otro por todos los participantes en la revisión. Revisiones técnicas y de gestión Por otro lado, según el objeto que se revise, se suele diferenciar entre las revisiones con orientación técnica y las revisionerevisiones de proyecto).

CALIDAD DE SOFTWARE

El proceso para realizar un walkthrough es mucho más sencillo y consta de tan sólo tres

1. Planificación: Similar a la planificación de una inspección, con la diferencia de que no es necesario asignar roles específicos a los participantes, a excepción del presentador, que es quien organiza el walkthrough y guía la reunión.

2. Preparación individual: Cada revisor examina el objeto revisado, aunque en este caso no se les entregará una lista de comprobación.

3. Reunión de walkthrough

La siguiente tabla resume las fases de inspecciones y walkthrough e indica los objetivos que se persiguen en cada una de ellas:

Inspección

Walkthrough

Objetivo

Etapas

Objetivo

Educación (grupo)

-

-


1. Preparación individual


Encontrar errores (grupo)

3. Reunión

Educación (grupo)Discusióndeerrores

Arreglar problemas

-

-

Asegurar que todos los problemas se han resuelto correctamente

-

-

Formalidad en las revisiones

diferenciar también entre las revisiones formales e informales. Se dice que una revisión es formal cuando:

Es un evento público Se informa por escrito de los resultados Todos los participantes son responsables de la calidad de la revisión.

ja de realizar revisiones formales es que los informes que se generan sirven como hitos para el proyecto, y el hecho de ser algo público promueve una mejor preparación por parte de los participantes. Por contra, la formalidad hace que este tipo de

s sean un tanto impersonales. Para evitar que los participantes se sientan intimidados por el ambiente impersonal y expresen libremente sus opiniones se pueden utilizar técnicas como el Roundconsiste en ir pasando el tumo de uno a otro por todos los participantes en la revisión.

Revisiones técnicas y de gestión

Por otro lado, según el objeto que se revise, se suele diferenciar entre las revisiones con orientación técnica y las revisiones orientadas a la gestión (también conocidas como

CALIDAD DE SOFTWARE

38

El proceso para realizar un walkthrough es mucho más sencillo y consta de tan sólo tres

Similar a la planificación de una inspección, con la diferencia de que no es necesario asignar roles específicos a los participantes, a excepción del presentador, que es quien organiza el walkthrough y guía la reunión.

sor examina el objeto revisado, aunque en

La siguiente tabla resume las fases de inspecciones y walkthrough e indica los objetivos que

Walkthrough

Objetivo - Educación (individual)

Educación (grupo) Discusión de alternativas de diseño Encontrar errores - -

diferenciar también entre las revisiones formales e informales. Se dice que una

Todos los participantes son responsables de la calidad de la revisión.

ja de realizar revisiones formales es que los informes que se generan sirven como hitos para el proyecto, y el hecho de ser algo público promueve una mejor preparación por parte de los participantes. Por contra, la formalidad hace que este tipo de

Para evitar que los participantes se sientan intimidados por el ambiente impersonal y Round-robin, que

consiste en ir pasando el tumo de uno a otro por todos los participantes en la revisión.

Por otro lado, según el objeto que se revise, se suele diferenciar entre las revisiones con s orientadas a la gestión (también conocidas como


Las revisiones técnicas más comunes son: - Revisión de la especificación de requisitos- Revisión del diseño- Revisión del código- Revisión de las pruebas- Revisión del manual d

Los principales objetivos que se buscan con las revisiones de proyecto, por otro lado, son los siguientes:

- Control de la progresión del proyecto- Evaluación de los riesgos asociados al proyecto, con relación al coste, escala de

tiempos, recursos- Evaluación general del producto.

Para que esto sea posible es necesario:

- Que exista un plan de desarrollo bien estructurado, con hitos bien definidos, que permita evaluar la progresión del proyecto.

- Que los resultadosya examinados en una revisión técnica.

A continuación vamos a examinar en más detalle las revisiones técnicas más comunes. Revisión de la especificación de requisitos Este tipo de revisión es mula especificación de requisitos en fases tempranas del desarrollo.El tipo de errores que se pueden encontrar en este objeto son:

- Requisitos poco claros, contradictorios, erróneos o i- Requisitos incompletos o especificación incompleta (faltan requisitos).- Requisitos irrelevantes para el problema que se trata de resolver.

Algunas de las preguntas que podrían encontrarse en una lista de comprobaciones para la especificación de requisitos son las siguientes:

- ¿Se han especificado todos los recursos hardware necesarios?- ¿Se han especificado las interfaces externas necesarias?- ¿Existen contradicciones en la especificación de los requisitos?- ¿Se han definido especificadas? - ¿Resulta comprensible la especificación realizada?

Revisión del diseño Se suele diferenciar entre la revisión del diseño preliminar o de alto nivel y la revisión del diseño detallado. El objetivo de estas revisiones es determinar y evaluar el estado en el que se encuentra el proceso de diseño, así como descubrir errores o contradicciones (entre la especificación de requisitos y el diseño o en las interfaces entre módulos)Algunas de las preguntas que podrían encontrarse en una lista de comprobaciones para el diseño son las siguientes:

- ¿Hay uniformidad en el diseño?- ¿Se han definido correctamente las interfaces entre módulos?- ¿Se han definido correctamente las interfaces - ¿Cubre el diseño todas las funciones incluidas en la especificación de requisitos?- ¿Cumple el diseño todos los requisitos no funcionales?

CALIDAD DE SOFTWARE

Las revisiones técnicas más comunes son:

Revisión de la especificación de requisitos Revisión del diseño Revisión del código Revisión de las pruebas Revisión del manual de usuario

Los principales objetivos que se buscan con las revisiones de proyecto, por otro lado, son los

Control de la progresión del proyecto Evaluación de los riesgos asociados al proyecto, con relación al coste, escala de tiempos, recursos utilizados y calidad del producto.

Evaluación general del producto. que esto sea posible es

Que exista un plan de desarrollo bien estructurado, con hitos bien definidos, que permita evaluar la progresión del proyecto. Que los resultados del proyecto se encuentren bien documentados y hayan sido ya examinados en una revisión técnica.

A continuación vamos a examinar en más detalle las revisiones técnicas más comunes.

Revisión de la especificación de requisitos

Este tipo de revisión es muy útil para facilitar el descubrimiento de los errores introducidos en la especificación de requisitos en fases tempranas del desarrollo. El tipo de errores que se pueden encontrar en este objeto son:

Requisitos poco claros, contradictorios, erróneos o imposibles de probarRequisitos incompletos o especificación incompleta (faltan requisitos).Requisitos irrelevantes para el problema que se trata de resolver.

Algunas de las preguntas que podrían encontrarse en una lista de comprobaciones para la cificación de requisitos son las siguientes:

¿Se han especificado todos los recursos hardware necesarios? ¿Se han especificado las interfaces externas necesarias? ¿Existen contradicciones en la especificación de los requisitos? ¿Se han definido los criterios de aceptación para cada una de las funciones

¿Resulta comprensible la especificación realizada?

Se suele diferenciar entre la revisión del diseño preliminar o de alto nivel y la revisión del etallado. El objetivo de estas revisiones es determinar y evaluar el estado en el que

se encuentra el proceso de diseño, así como descubrir errores o contradicciones (entre la especificación de requisitos y el diseño o en las interfaces entre módulos)

nas de las preguntas que podrían encontrarse en una lista de comprobaciones para el diseño son las siguientes:

¿Hay uniformidad en el diseño? ¿Se han definido correctamente las interfaces entre módulos? ¿Se han definido correctamente las interfaces extemas? ¿Cubre el diseño todas las funciones incluidas en la especificación de requisitos?¿Cumple el diseño todos los requisitos no funcionales?

CALIDAD DE SOFTWARE

39

Los principales objetivos que se buscan con las revisiones de proyecto, por otro lado, son los

Evaluación de los riesgos asociados al proyecto, con relación al coste, escala de

Que exista un plan de desarrollo bien estructurado, con hitos bien definidos, que

del proyecto se encuentren bien documentados y hayan sido

A continuación vamos a examinar en más detalle las revisiones técnicas más comunes.

y útil para facilitar el descubrimiento de los errores introducidos en

mposibles de probar Requisitos incompletos o especificación incompleta (faltan requisitos). Requisitos irrelevantes para el problema que se trata de resolver.

Algunas de las preguntas que podrían encontrarse en una lista de comprobaciones para la

los criterios de aceptación para cada una de las funciones

Se suele diferenciar entre la revisión del diseño preliminar o de alto nivel y la revisión del etallado. El objetivo de estas revisiones es determinar y evaluar el estado en el que

se encuentra el proceso de diseño, así como descubrir errores o contradicciones (entre la especificación de requisitos y el diseño o en las interfaces entre módulos)

nas de las preguntas que podrían encontrarse en una lista de comprobaciones para el

¿Cubre el diseño todas las funciones incluidas en la especificación de requisitos?


- ¿Resulta ambigua la documentación del diseño?- ¿Se ha aplicado la notación de diseño correctamente?- ¿Es el diseño lo suficientemente detallado como para que sea posible impí ementarlo en el lenguaje de programación elegido?

Revisión del código Las revisiones del código suelen tomar la forma de revisión por pares o inspección, y uno de sus objetivos es determinar que el código se corresponde con el diseño detallado realizado.Algunos de los aspectos que se examinan en una revisión de código son los siguientes:

- interfaces - estructura del programa- utilización de variables- fórmulas - entradas y salidas- comentarios - adherencia a los estándares de codificación

Las revisiones de código se basan en la lectura del mismo, lo que exige de los programadores un esfuerzo para hacerlo legible.Los estudios realizados demuestran que, mediante las inspeccmitad de los errores de programación se pueden detectar antes de pasar a la prueba modular y que los programas que han pasado por una inspección de código contienen considerablemente menos errores. Revisiones de las pruebas Se pueden efectuar dos tipos de revisiones de las pruebas:

- Revisión del diseño de la prueba- Inspección de la prueba

El objetivo de la revisión del diseño de la prueba es comprobar que el diseño realizado para la prueba está de acuerdo con los objetivoscomo:

- ¿Se han tenido en cuenta todos los objetivos a la hora de diseñar los casos de prueba? - ¿Se han elegido los casos de prueba más adecuados para comprobar la consecución de dichos objetivos?

Los objetivos de las inspecciones de las pruebas, por su parte, son:

- Comprobar que la prueba se ha ejecutado correctamente, de acuerdo con el procedimiento de prueba especificado.- Análisis de los resultados obtenidos con cada prueba.

Controles Estáticos Automáticos

Dentro de esta categoría tenemos el análisis estático automático y la verificación formal de programas. La mayor parte del análisis estático automático del código lo realizan los pueden detectar desde expresiones sintáctde tipo y otros errores de tipo semántico. Verificación formal

CALIDAD DE SOFTWARE

¿Resulta ambigua la documentación del diseño? ¿Se ha aplicado la notación de diseño correctamente? ¿Es el diseño lo suficientemente detallado como para que sea posible impí ementarlo

en el lenguaje de programación elegido?

Las revisiones del código suelen tomar la forma de revisión por pares o inspección, y uno de determinar que el código se corresponde con el diseño detallado realizado.

Algunos de los aspectos que se examinan en una revisión de código son los siguientes:

estructura del programa utilización de variables

salidas

adherencia a los estándares de codificación

Las revisiones de código se basan en la lectura del mismo, lo que exige de los programadores un esfuerzo para hacerlo legible. Los estudios realizados demuestran que, mediante las inspecciones de código, más de la mitad de los errores de programación se pueden detectar antes de pasar a la prueba modular y que los programas que han pasado por una inspección de código contienen considerablemente menos errores.

Revisiones de las pruebas

pueden efectuar dos tipos de revisiones de las pruebas:

Revisión del diseño de la prueba Inspección de la prueba

El objetivo de la revisión del diseño de la prueba es comprobar que el diseño realizado para la prueba está de acuerdo con los objetivos que se persiguen. Se deben comprobar aspectos

¿Se han tenido en cuenta todos los objetivos a la hora de diseñar los casos de

¿Se han elegido los casos de prueba más adecuados para comprobar la consecución de dichos objetivos?

vos de las inspecciones de las pruebas, por su parte, son:

Comprobar que la prueba se ha ejecutado correctamente, de acuerdo con el procedimiento de prueba especificado.

Análisis de los resultados obtenidos con cada prueba.

Automáticos

Dentro de esta categoría tenemos el análisis estático automático y la verificación formal de

La mayor parte del análisis estático automático del código lo realizan los pueden detectar desde expresiones sintácticamente incorrectas hasta incompatibilidades de tipo y otros errores de tipo semántico.

CALIDAD DE SOFTWARE

40

¿Es el diseño lo suficientemente detallado como para que sea posible impí ementarlo

Las revisiones del código suelen tomar la forma de revisión por pares o inspección, y uno de determinar que el código se corresponde con el diseño detallado realizado.

Algunos de los aspectos que se examinan en una revisión de código son los siguientes:

Las revisiones de código se basan en la lectura del mismo, lo que exige de los programadores

iones de código, más de la mitad de los errores de programación se pueden detectar antes de pasar a la prueba modular y que los programas que han pasado por una inspección de código contienen

El objetivo de la revisión del diseño de la prueba es comprobar que el diseño realizado para la que se persiguen. Se deben comprobar aspectos

¿Se han tenido en cuenta todos los objetivos a la hora de diseñar los casos de

¿Se han elegido los casos de prueba más adecuados para comprobar la consecución

Comprobar que la prueba se ha ejecutado correctamente, de acuerdo con el

Dentro de esta categoría tenemos el análisis estático automático y la verificación formal de

La mayor parte del análisis estático automático del código lo realizan los compiladores, que icamente incorrectas hasta incompatibilidades


Consiste en demostrar matemáticamente la corrección de un programa con respecto a sus especificaciones. Para ello, se considera el programa colenguaje formal, con una sintaxis y una semántica formal. Es también necesario que la especificación se haya escrito en algún lenguaje formal. Por eso no siempre es posible realizar este tipo de verificación. Por lo general, esta técnica sólo se utiliza para sistemas críticos, debido al coste que conlleva. Los métodos de verificación formal de programas más conocidos son los basados en la lógica de Hoare [Hoare, 1969], los basados en la aproximación de aproximación funcional de Milis [Milis, 1987].

Introducción

Se llama controles dinámicos a aquellos que requieren la ejecución del objeto que se está probando o de un modelo del mismo.Hasta la fecha no se ha desarrollado ninguna teoría universalmente aceptada acerca de la prueba de software. Lo único que hay es un conjunto de aproximaciones metodológicas que facilitan y hacen más eficiente el proceso de prueba. Se llama PRUEBA del Software al procesodetectar fallos. Se llama DEPURACIÓN al proceso en el que se localiza el defecto que es la causa de un fallo, se determina la forma de corregirlo, se evalúa el efecto de la corrección y se lleva a cabo lcorrección. Por lo general, después del proceso de depuración será necesario repetir el proceso de prueba, para garantizar que el defecto quedó efectivamente corregido y que no se introdujeron nuevos defectos. El coste de detección de los defectos suelemismos, y este es un punto en contra de las pruebas como técnica de control de calidad, ya que siempre es necesario un paso de diagnóstico hasta que se localiza la causa de los fallos. En otras actividades de control de calidad, por el contrario, como pueden ser las revisiones, se localizan directamente los defectos, no sus síntomas, por lo que nos ahorramos el proceso de diagnóstico. En un proyecto grande la prueba se puede llevar hasta el 50 o 60% del esproyecto. Por eso es muy importante seleccionar bien las pruebas que se van a realizar, teniendo en cuenta que sólo las pruebas que revelan defectos son las que realmente merecen la pena. El objetivo del proceso de prueba no es, como puestá libre de defectos, sino precisamente descubrir defectos. Por ello, se deben seleccionar especialmente aquellos casos de prueba que incidan en las secciones del programa más complejas, en los valores límite de l Aunque la prueba es una parte importante del Control de Calidad, es importante darse cuenta de que no es la única. A continuación veremos cuáles son las actividades que es necesario realizar para probar sistema software, y cuáles son los principales métodos de prueba que se pueden utilizar.

CALIDAD DE SOFTWARE

Consiste en demostrar matemáticamente la corrección de un programa con respecto a sus

Para ello, se considera el programa como un objeto formal, es decir, como una cadena de un lenguaje formal, con una sintaxis y una semántica formal. Es también necesario que la especificación se haya escrito en algún lenguaje formal. Por eso no siempre es posible realizar

Por lo general, esta técnica sólo se utiliza para sistemas críticos, debido al coste que conlleva.

Los métodos de verificación formal de programas más conocidos son los basados en la lógica de Hoare [Hoare, 1969], los basados en la aproximación de Dijkstra [Dijkstra, 1989] y la aproximación funcional de Milis [Milis, 1987].

CONTROLES DINÁMICOS

Se llama controles dinámicos a aquellos que requieren la ejecución del objeto que se está probando o de un modelo del mismo.

no se ha desarrollado ninguna teoría universalmente aceptada acerca de la prueba de software. Lo único que hay es un conjunto de aproximaciones metodológicas que facilitan y hacen más eficiente el proceso de prueba.

Se llama PRUEBA del Software al proceso en el que se ejecuta un sistema con el objetivo de

Se llama DEPURACIÓN al proceso en el que se localiza el defecto que es la causa de un fallo, se determina la forma de corregirlo, se evalúa el efecto de la corrección y se lleva a cabo lcorrección. Por lo general, después del proceso de depuración será necesario repetir el proceso de prueba, para garantizar que el defecto quedó efectivamente corregido y que no se introdujeron nuevos defectos.

El coste de detección de los defectos suele ser mucho mayor que el coste de corrección de los mismos, y este es un punto en contra de las pruebas como técnica de control de calidad, ya que siempre es necesario un paso de diagnóstico hasta que se localiza la causa de los fallos.

de control de calidad, por el contrario, como pueden ser las revisiones, se localizan directamente los defectos, no sus síntomas, por lo que nos ahorramos el proceso de

En un proyecto grande la prueba se puede llevar hasta el 50 o 60% del esproyecto. Por eso es muy importante seleccionar bien las pruebas que se van a realizar, teniendo en cuenta que sólo las pruebas que revelan defectos son las que realmente merecen

El objetivo del proceso de prueba no es, como pudiera parecer, demostrar que el software está libre de defectos, sino precisamente descubrir defectos. Por ello, se deben seleccionar especialmente aquellos casos de prueba que incidan en las secciones del programa más complejas, en los valores límite de las variables, en la tolerancia a fallos del diseño.

Aunque la prueba es una parte importante del Control de Calidad, es importante darse cuenta

A continuación veremos cuáles son las actividades que es necesario realizar para probar sistema software, y cuáles son los principales métodos de prueba que se pueden utilizar.

CALIDAD DE SOFTWARE

41

Consiste en demostrar matemáticamente la corrección de un programa con respecto a sus

mo un objeto formal, es decir, como una cadena de un lenguaje formal, con una sintaxis y una semántica formal. Es también necesario que la especificación se haya escrito en algún lenguaje formal. Por eso no siempre es posible realizar

Por lo general, esta técnica sólo se utiliza para sistemas críticos, debido al coste que conlleva.

Los métodos de verificación formal de programas más conocidos son los basados en la lógica Dijkstra [Dijkstra, 1989] y la

Se llama controles dinámicos a aquellos que requieren la ejecución del objeto que se está

no se ha desarrollado ninguna teoría universalmente aceptada acerca de la prueba de software. Lo único que hay es un conjunto de aproximaciones metodológicas que

en el que se ejecuta un sistema con el objetivo de

Se llama DEPURACIÓN al proceso en el que se localiza el defecto que es la causa de un fallo, se determina la forma de corregirlo, se evalúa el efecto de la corrección y se lleva a cabo la corrección. Por lo general, después del proceso de depuración será necesario repetir el proceso de prueba, para garantizar que el defecto quedó efectivamente corregido y que no se

ser mucho mayor que el coste de corrección de los mismos, y este es un punto en contra de las pruebas como técnica de control de calidad, ya que siempre es necesario un paso de diagnóstico hasta que se localiza la causa de los fallos.

de control de calidad, por el contrario, como pueden ser las revisiones, se localizan directamente los defectos, no sus síntomas, por lo que nos ahorramos el proceso de

En un proyecto grande la prueba se puede llevar hasta el 50 o 60% del esfuerzo dedicado al proyecto. Por eso es muy importante seleccionar bien las pruebas que se van a realizar, teniendo en cuenta que sólo las pruebas que revelan defectos son las que realmente merecen

diera parecer, demostrar que el software está libre de defectos, sino precisamente descubrir defectos. Por ello, se deben seleccionar especialmente aquellos casos de prueba que incidan en las secciones del programa más

as variables, en la tolerancia a fallos del diseño.

Aunque la prueba es una parte importante del Control de Calidad, es importante darse cuenta

A continuación veremos cuáles son las actividades que es necesario realizar para probar un sistema software, y cuáles son los principales métodos de prueba que se pueden utilizar.


Tipos de pruebas

El proceso de prueba conlleva la realización de un conjunto de tareas a lo largo del ciclo de vida del sistema. De acuerdo con el estándar IEEE 1que se deben realizar son:

� La prueba modular consiste en la prueba de cada módulo aislado del resto del sistema. � La prueba de integración

integran en el mismo. Ya se ha realizado la prueba modular, y se supone que todos módulos son correctos. El objetivo fundamental de esta prueba es comprobar que las interfaces entre los distintes necesario realizar son:

- Corrección en la sintaxis en la invocación de procedimientos y funciones.- Compatibilidad de tipos entre los argumentos del procedimiento o función y los

parámetros de l- Corrección y completitud de las especificaciones de los módulos. Se

utilizar tres posibles estrategias de integración:- De arriba a abajo (top

los módulos que están en los niveles sncrementalmente los niveles inferiores.

- De abajo a arriba (bottomlos módulos que están en los niveles inferiores de abstracción, e integrar incrementalmente los

- De big-bang: Consiste en integrar y probar todo al mismo tiempo. � La prueba del sistema

es comprobar que el sistema satisface los requisitos del usuario, tanto los funcomo los no funcionales.

� La prueba de aceptación

real de funcionamiento, y su objetivo es demostrar al usuario que el sistema satisface sus necesidades.

CALIDAD DE SOFTWARE

El proceso de prueba conlleva la realización de un conjunto de tareas a lo largo del ciclo de vida del sistema. De acuerdo con el estándar IEEE 1012-1986 el conjunto mínimo de pruebas que se deben realizar son:

consiste en la prueba de cada módulo aislado del resto del sistema.

La prueba de integración se realiza a medida que los diferentes módulos del sistema se integran en el mismo. Ya se ha realizado la prueba modular, y se supone que todos módulos son correctos. El objetivo fundamental de esta prueba es comprobar que las interfaces entre los distintos módulos son correctas. Algunas de las comprobaciones que es necesario realizar son:

Corrección en la sintaxis en la invocación de procedimientos y funciones.Compatibilidad de tipos entre los argumentos del procedimiento o función y los parámetros de llamada. Corrección y completitud de las especificaciones de los módulos. Se utilizar tres posibles estrategias de integración: De arriba a abajo (top-down): Consiste en empezar la integración y la prueba por los módulos que están en los niveles superiores de abstracción, e integrar ncrementalmente los niveles inferiores. De abajo a arriba (bottom-up): Consiste en empezar la integración y la prueba por los módulos que están en los niveles inferiores de abstracción, e integrar

incrementalmente los niveles superiores. bang: Consiste en integrar y probar todo al mismo tiempo.

prueba del sistema se realiza cuando se han integrado todos los módulos, y su objetivo es comprobar que el sistema satisface los requisitos del usuario, tanto los funcomo los no funcionales.

prueba de aceptación se realiza una vez que el sistema se ha implantado en su entorno real de funcionamiento, y su objetivo es demostrar al usuario que el sistema satisface sus

CALIDAD DE SOFTWARE

42

El proceso de prueba conlleva la realización de un conjunto de tareas a lo largo del ciclo de 1986 el conjunto mínimo de pruebas

consiste en la prueba de cada módulo aislado del resto del sistema.

se realiza a medida que los diferentes módulos del sistema se integran en el mismo. Ya se ha realizado la prueba modular, y se supone que todos módulos son correctos. El objetivo fundamental de esta prueba es comprobar que las

os módulos son correctas. Algunas de las comprobaciones que

Corrección en la sintaxis en la invocación de procedimientos y funciones. Compatibilidad de tipos entre los argumentos del procedimiento o función y los

Corrección y completitud de las especificaciones de los módulos. Se pueden

down): Consiste en empezar la integración y la prueba por uperiores de abstracción, e integrar

up): Consiste en empezar la integración y la prueba por los módulos que están en los niveles inferiores de abstracción, e integrar

bang: Consiste en integrar y probar todo al mismo tiempo.

se realiza cuando se han integrado todos los módulos, y su objetivo es comprobar que el sistema satisface los requisitos del usuario, tanto los funcionales

se realiza una vez que el sistema se ha implantado en su entorno real de funcionamiento, y su objetivo es demostrar al usuario que el sistema satisface sus


A continuación vamos a ver los dos grupos en que se clasifican los métodos de prueba:

- Métodos de caja negra- Métodos de caja blanca

Métodos de caja negra

En este tipo de métodos, el objeto que se desea probar se ve como una caja negra. Esto quiere decir que la elección dese tenga acerca de la estructura del objeto, sino en el conocimiento acerca de la funcionalidad deseada (descripción funcional).funcional o prueba orientada al diseño.generación de un caso de prueba por cada combinación posible (válida o no válida) de los valores de entrada, lo cual resulta imposible en la mayor parte de los casos por producirsuna explosión combinatoria. Por eso se utilizan diferentes criterios a la hora de restringir el conjunto de casos de prueba.usuales son:

Método de clases de equivalenciaConsiste en dividir lforma que todos los miembros de una misma clase de equivalencia prueben las mismas propiedades en el sistema, por lo que sólo va a ser necesario seleccionar un elemento de cada clase de equi Análisis de valores frontera o valores límiteConsiste en seleccionar como casos de prueba aquellos valores de entrada que caen

CALIDAD DE SOFTWARE

ver los dos grupos en que se clasifican los métodos de prueba:

Métodos de caja negra Métodos de caja blanca

En este tipo de métodos, el objeto que se desea probar se ve como una caja negra. Esto quiere decir que la elección de los casos de prueba no se va a basar en el conocimiento que se tenga acerca de la estructura del objeto, sino en el conocimiento acerca de la funcionalidad deseada (descripción funcional). A la prueba de caja negra también se le llama prueba

rueba orientada al diseño. Una prueba de caja negra exhaustiva requeriría la generación de un caso de prueba por cada combinación posible (válida o no válida) de los valores de entrada, lo cual resulta imposible en la mayor parte de los casos por producirsuna explosión combinatoria. Por eso se utilizan diferentes criterios a la hora de restringir el conjunto de casos de prueba. Los métodos de selección del conjunto de casos de prueba más

Método de clases de equivalencia Consiste en dividir las posibles entradas al sistema en clases de equivalencia, de tal forma que todos los miembros de una misma clase de equivalencia prueben las mismas propiedades en el sistema, por lo que sólo va a ser necesario seleccionar un elemento de cada clase de equivalencia.

Análisis de valores frontera o valores límite Consiste en seleccionar como casos de prueba aquellos valores de entrada que caen

CALIDAD DE SOFTWARE

43

ver los dos grupos en que se clasifican los métodos de prueba:

En este tipo de métodos, el objeto que se desea probar se ve como una caja negra. Esto los casos de prueba no se va a basar en el conocimiento que

se tenga acerca de la estructura del objeto, sino en el conocimiento acerca de la funcionalidad A la prueba de caja negra también se le llama prueba

Una prueba de caja negra exhaustiva requeriría la generación de un caso de prueba por cada combinación posible (válida o no válida) de los valores de entrada, lo cual resulta imposible en la mayor parte de los casos por producirse una explosión combinatoria. Por eso se utilizan diferentes criterios a la hora de restringir el

Los métodos de selección del conjunto de casos de prueba más

as posibles entradas al sistema en clases de equivalencia, de tal forma que todos los miembros de una misma clase de equivalencia prueben las mismas propiedades en el sistema, por lo que sólo va a ser necesario seleccionar un

Consiste en seleccionar como casos de prueba aquellos valores de entrada que caen


en la frontera de las clases de equivalencia (justo a un lado, justo al otro y justo en la frontera). Grafos causa/efConsiste en crear un grafo causa/efecto a partir de las especificaciones, y seleccionar suficientes casos de prueba como para asegurar la cobertura del grafo. Se llama causas a las características de los datos de entrada y efectosque puede proporcionar el programa. A partir del grafo causa/efecto se construye una tabla de decisión que refleje las dependencias entre causas y efectos. Lo que se hace entonces es reducir la tabla de decisión y seleccionar sólo todas las causas que producen el mismo efecto, o para cada columna de la tabla de decisión. Adivinación de erroresConsiste en tratar de imaginar cuáles son los errores que se pueden haber cometido con mayor probabilidad, y generar

Métodos de caja blanca

En este tipo de métodos, el objeto que se desea probar se ve como una caja blanca. Esto quiere decir que la elección de los casos de prueba se va a basar en el conocimiento que se tenga acerca de la estructura del objeto (diseño detallado, diagramas de flujo de datos y de control, código fuente). A la prueba de caja blanca también se le llama prueba estructural.métodos de caja blanca se pueden clasificar, a su vez, en dos grupométricas de cobertura y los basados en métricas de complejidad 1. Métodos basados en métricas de cobertura: Todo programa se puede representar mediante un grafo de flujo de control, donde cada nodo es una sentencia o una secuencia de sflujo de control. Para cada conjunto de datos de entrada el programa se ejecutará a través de un camino concreto dentro de este grafo. Cuando el programa incluye estructuras iterativas, el número de posibles caminos en el grafo puede ser infinito.exhaustiva requeriría la generación de un caso de prueba por cada posible camino. Como esto no es posible, por lo general, se utilizan métricas que dan una indicación de la calidaddeterminado conjunto de casos de prueba en función del grado de cobertura del grafo que consiguen. Las métricas más utilizadas son:

- Cobertura de sentencias- Cobertura de segmentos entre decisiones.- Cobertura de decisiones de ramificación- Cobertura de condiciones- Cobertura de todas las combinaciones de condiciones- Cobertura de caminos

2. Métodos basados en métricas de complejidad: Las métricas de complejidad más utilizadas en la generación de casos de prueba son las de MacCabe:

- Complejidad ciclomática (arcos - Complejidad esencial (complejidad ciclomática

de entrada y salida única)- Complejidad real (número de caminos ejecutados)

Metodología de prueba

Cada uno de los diferentes tipos de prueba implica la realización de un conjunto de actividades estándar, así como la producción de un conjunto de salidas estándar.

CALIDAD DE SOFTWARE

en la frontera de las clases de equivalencia (justo a un lado, justo al otro y justo en la

Grafos causa/efecto y tablas de decisión Consiste en crear un grafo causa/efecto a partir de las especificaciones, y seleccionar suficientes casos de prueba como para asegurar la cobertura del grafo. Se llama causas a las características de los datos de entrada y efectos a las clases de salidas que puede proporcionar el programa. A partir del grafo causa/efecto se construye una tabla de decisión que refleje las dependencias entre causas y efectos. Lo que se hace entonces es reducir la tabla de decisión y seleccionar sólo un caso de prueba para todas las causas que producen el mismo efecto, o para cada columna de la tabla de

Adivinación de errores Consiste en tratar de imaginar cuáles son los errores que se pueden haber cometido con mayor probabilidad, y generar casos de prueba para comprobar dichos errores.

En este tipo de métodos, el objeto que se desea probar se ve como una caja blanca. Esto quiere decir que la elección de los casos de prueba se va a basar en el conocimiento que se tenga acerca de la estructura del objeto (diseño detallado, diagramas de flujo de datos y de

A la prueba de caja blanca también se le llama prueba estructural.métodos de caja blanca se pueden clasificar, a su vez, en dos grupo

los basados en métricas de complejidad

Métodos basados en métricas de cobertura:

Todo programa se puede representar mediante un grafo de flujo de control, donde cada nodo es una sentencia o una secuencia de sentencias. Los arcos dirigidos en el grafo representan el

Para cada conjunto de datos de entrada el programa se ejecutará a través de un camino concreto dentro de este grafo. Cuando el programa incluye estructuras iterativas,

posibles caminos en el grafo puede ser infinito. Una prueba de caja blanca exhaustiva requeriría la generación de un caso de prueba por cada posible camino. Como esto no es posible, por lo general, se utilizan métricas que dan una indicación de la calidaddeterminado conjunto de casos de prueba en función del grado de cobertura del grafo que consiguen. Las métricas más utilizadas son:

Cobertura de sentencias Cobertura de segmentos entre decisiones. Cobertura de decisiones de ramificación

rtura de condiciones Cobertura de todas las combinaciones de condiciones Cobertura de caminos

Métodos basados en métricas de complejidad:

Las métricas de complejidad más utilizadas en la generación de casos de prueba son las de

Complejidad ciclomática (arcos - nodos + 2 * número de componentes Complejidad esencial (complejidad ciclomática - número de subgrafos propios

de entrada y salida única) Complejidad real (número de caminos ejecutados)

ada uno de los diferentes tipos de prueba implica la realización de un conjunto de actividades estándar, así como la producción de un conjunto de salidas estándar.

CALIDAD DE SOFTWARE

44

en la frontera de las clases de equivalencia (justo a un lado, justo al otro y justo en la

Consiste en crear un grafo causa/efecto a partir de las especificaciones, y seleccionar suficientes casos de prueba como para asegurar la cobertura del grafo. Se llama

a las clases de salidas que puede proporcionar el programa. A partir del grafo causa/efecto se construye una tabla de decisión que refleje las dependencias entre causas y efectos. Lo que se hace

un caso de prueba para todas las causas que producen el mismo efecto, o para cada columna de la tabla de

Consiste en tratar de imaginar cuáles son los errores que se pueden haber cometido casos de prueba para comprobar dichos errores.

En este tipo de métodos, el objeto que se desea probar se ve como una caja blanca. Esto quiere decir que la elección de los casos de prueba se va a basar en el conocimiento que se tenga acerca de la estructura del objeto (diseño detallado, diagramas de flujo de datos y de

A la prueba de caja blanca también se le llama prueba estructural. Los métodos de caja blanca se pueden clasificar, a su vez, en dos grupos: Los basados en

Todo programa se puede representar mediante un grafo de flujo de control, donde cada nodo entencias. Los arcos dirigidos en el grafo representan el

Para cada conjunto de datos de entrada el programa se ejecutará a través de un camino concreto dentro de este grafo. Cuando el programa incluye estructuras iterativas,

Una prueba de caja blanca exhaustiva requeriría la generación de un caso de prueba por cada posible camino. Como esto no es posible, por lo general, se utilizan métricas que dan una indicación de la calidad de un determinado conjunto de casos de prueba en función del grado de cobertura del grafo que

Las métricas de complejidad más utilizadas en la generación de casos de prueba son las de

nodos + 2 * número de componentes conexos) número de subgrafos propios

ada uno de los diferentes tipos de prueba implica la realización de un conjunto de actividades estándar, así como la producción de un conjunto de salidas estándar.


Actividades Estándar de la Prueba

Planificación de la prueba.

Diseño de la prueba.

Determinación de los casos de prueba.

Planificación del procedimiento de prueba.

Ejecución de la prueba.

Análisis y evaluación

1. Planificación de la prueba:pruebas en el que se registra:

- El objetivo del proceso de prueba.- Los objetos que hay que probar.-Las características que se van a probar y las que no.- El método de prueba a utilizar.- Los recursos que se van a emplear.- El plan de tiempos.- Los productos a generar durante las pruebas- El reparto de las responsabilida

2. Diseño de la prueba:

- cómo llevar a cabo la prueba para alcanzar los objetivos deseados,- de qué forma se van a utilizar los métodos de prueba,- qué objetos se van a probar en c- qué criterios se van a utilizar para determinar si el objeto pasa o no pasa la prueba.

3. Determinación de los casos de prueba:conjunto de casos de prueba a utilizar en función del disecada caso de prueba habrá que especificar:

- qué objetos se van a probar,- qué entradas se les van a dar y- cuáles son las salidas esperadas.

4. Planificación del procedimiento de prueba:conjunto de pasos para la ejecución de la prueba. Se especifica detalladamente:

- la secuencia exacta de ejecución de los distintos casos de prueba,- los requisitos que hay que cumplir para la ejecución de cada caso y- las condiciones de terminación de cada uno de ellos.

5. Ejecución de la prueba:el procedimiento especificado en el paso anterior, y registrar los incidentes o problemas encontrados durante la misma.

6. Análisis y evaluación de la prueba:se han alcanzado los objetivos propuestos o se debe repetir la prueba.

==

CALIDAD DE SOFTWARE

Actividades Estándar de la Prueba Salidas Estándar asociadasPlanificación de la prueba. Plan de prueba.

Diseño de la prueba. Documento de diseño de la prueba.

Determinación de los casos de prueba. Especificación de los casos de prueba.

Planificación del procedimiento de prueba. Especificación del procedimiento de prueba.

prueba. Informe de los casos de prueba.

de prueba. Informe de la prueba.

1. Planificación de la prueba: Esta actividad consiste en la creación de un plan de pruebas en el que se registra:

El objetivo del proceso de prueba. objetos que hay que probar.

Las características que se van a probar y las que no. El método de prueba a utilizar. Los recursos que se van a emplear. El plan de tiempos. Los productos a generar durante las pruebas El reparto de las responsabilidades.

2. Diseño de la prueba: Esta actividad consiste en dar instrucciones detalladas acerca de:cómo llevar a cabo la prueba para alcanzar los objetivos deseados,

de qué forma se van a utilizar los métodos de prueba, qué objetos se van a probar en cada una de las pruebas y qué criterios se van a utilizar para determinar si el objeto pasa o no pasa la prueba.

3. Determinación de los casos de prueba: Esta actividad consiste en especificar el conjunto de casos de prueba a utilizar en función del diseño realizado para la prueba. Para cada caso de prueba habrá que especificar:

qué objetos se van a probar, qué entradas se les van a dar y cuáles son las salidas esperadas.

4. Planificación del procedimiento de prueba: Esta actividad consiste en fijar un conjunto de pasos para la ejecución de la prueba. Se especifica detalladamente:

la secuencia exacta de ejecución de los distintos casos de prueba,los requisitos que hay que cumplir para la ejecución de cada caso ylas condiciones de terminación de cada uno de ellos.

5. Ejecución de la prueba: Esta actividad consiste en ejecutar cada caso de prueba, según el procedimiento especificado en el paso anterior, y registrar los incidentes o problemas

la misma.

Análisis y evaluación de la prueba: Se examinan los resultados de la prueba y se decide si se han alcanzado los objetivos propuestos o se debe repetir la prueba.

== FIN DE LA ASIGNATURA ==

CALIDAD DE SOFTWARE

45

Estándar asociadas Plan de prueba.

Documento de diseño de la prueba.

Especificación de los casos de prueba.

Especificación del procedimiento de prueba.

Informe de los casos de prueba.

Informe de la prueba.

Esta actividad consiste en la creación de un plan de

Esta actividad consiste en dar instrucciones detalladas acerca de: cómo llevar a cabo la prueba para alcanzar los objetivos deseados,

qué criterios se van a utilizar para determinar si el objeto pasa o no pasa la prueba.

Esta actividad consiste en especificar el ño realizado para la prueba. Para

Esta actividad consiste en fijar un conjunto de pasos para la ejecución de la prueba. Se especifica detalladamente:

la secuencia exacta de ejecución de los distintos casos de prueba, los requisitos que hay que cumplir para la ejecución de cada caso y

Esta actividad consiste en ejecutar cada caso de prueba, según el procedimiento especificado en el paso anterior, y registrar los incidentes o problemas

Se examinan los resultados de la prueba y se decide si

Documents

Calidad de Software - Material de Estudio