Ensayo
ENSAYO
Resumen
Se describe la incursión de la informática dentro de las empresas, de un
modo generalista los diferentes caminos para obtener la calidad de software, por eso en este ensayo se
describe los diferentes método de control en la calidad y desarrollo
de software.
El desarrollo de software basado en componentes se ha convertido actualmente en
uno de los mecanismos más efectivos para la construcción de grandes sistemas y
aplicaciones de software. Una vez que la mayor parte de los aspectos
funcionales de esta disciplina comienzan a estar bien definidos, la atención de
la comunidad científica comienza a centrarse en los aspectos extra funcionales
y de calidad, como un paso hacia una verdadera ingeniería.
Palabras claves
Calidad en el desarrollo del
software, mecanismos de control, características y gestión de calidad, ISO,
IEEE.
Introducción
La obtenció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 de desarrollo
como para el control
de la calidad del software.
Los requisitos del software son la base
de las medidas de calidad. La falta de concordancia con los requisitos es una
falta de calidad.
Los estándares o metodologías definen un
conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería
del software.
Si no se sigue ninguna metodología
siempre habrá falta de calidad.
DESARROLLO
CALIDAD EN EL DESARROLLO DE SOFTWARE
Actualmente existe un gran interés por
la calidad de los productos o servicios. En el mercado actual que es tan
competitivo no basta con producir y distribuir los productos o servicios,
vender es lo importante y esto se genera con la aceptación por parte del
cliente, se dice que la calidad no tiene un concepto solo se reconoce. Sin
embargo la calidad en el software es un concepto complejo que no es
directamente comparable con la calidad de un producto. El software se ha
convertido en la actualidad en uno de los principales objetivos estratégicos de
las organizaciones debido a que, cada día, los procesos más importantes de las
organizaciones y su supervivencia dependen del funcionamiento del software.
Según Pressman (2005), es la
concordancia del software producido con los requerimientos explícitamente
establecidos y con los estándares de desarrollo prefijados y con los
requerimientos implícitos no establecidos formalmente, que desea el
usuario. Otra definición que contempla Vega, Rivera & García (2008)
en su libro. Y que es propuesta por la organización internacional de estándares
(ISO/IEC DEC 9126): “La totalidad de características de un producto de software
que tienen como habilidad, satisfacer necesidades explícitas o implícitas”.
La calidad del software se puede
observar en una característica o atributo. Como un atributo, la calidad se
refiere a características mensurables, es decir cosas que se pueden comparar
para conocer estándares, como longitud, color, propiedades eléctricas y
maleabilidad. Sin embargo, el software que es una entidad intelectual, tiene la
complejidad de caracterizar los objetos físicos. No obstante, existen
mediciones que nos permiten evaluar las características de un programa. Dichas
propiedades incluyen complejidad psicosomática, número de puntos de función,
líneas de código, etcétera. Cuando se examina un elemento sus
características mensurables se pueden encontrar dos tipos de calidad:
- Calidad de diseño; la calidad de diseño se
refiere a las características que los diseñadores especifican para un
elemento.
- Calidad de concordancia; la calidad de concordancia
es el grado en el que las especificaciones de diseño se aplican durante la
fabricación.
En el desarrollo de software la calidad
del diseño incluye requisitos, especificaciones y el diseño del sistema. La
calidad de concordancia es un tema enfocado principalmente a la implementación.
Si el diseño y el sistema resultante satisfacen los requisitos y metas de
desempeño, la calidad de concordancia es alta. Glass (1998), argumenta que es
conveniente generar una relación más intuitiva.
Satisfacción del
usuario = producto manejable + buena calidad + entrega dentro del presupuesto y
tiempo.
Glass (1998), afirma que la calidad es
importante, pero si el usuario no está satisfecho, nada más importa en
realidad. De igual forma afirma que la calidad de un producto es una función de
cuánto cambia el mundo para mejorar. Esta visión de la calidad afirma que si un
software proporciona beneficio sustancial a sus usuarios finales, éstos están
dispuestos a tolerar problemas ocasionales en aspectos como la confiabilidad y
el desempeño.
- Control de calidad.
El control de la variación puede
equipararse con el control de calidad. Esto involucra la serie de inspecciones,
revisiones y pruebas empleadas a lo largo del proceso del software para
garantizar que cada producto del trabajo satisfaga los requisitos que se le han
asignado. El control de calidad incluye un bucle de retroalimentación con el
proceso que creó el producto del trabajo. La combinación de mediciones
retroalimentación permite afinar el proceso cuando los productos de trabajo
creados fracasan en cuanto a satisfacer sus especificaciones. Un concepto clave
del control de calidad es que todos los productos de trabajo tienen
especificaciones definidas mensurables con las cuales se puede comparar la
salida de cada proceso. Dicho bucle es esencial para minimizar los efectos
producidos.
- Garantía de la calidad.
La garantía de la calidad consiste en
un conjunto de funciones de auditoría e información que evalúan la efectividad
y qué tan completa son las actividades de control de calidad. La meta del
aseguramiento de la calidad es presentarle al gestor los datos necesarios para
que esté informado acerca de la calidad del producto y por consiguiente que
comprenda y confíe en que la calidad del producto está satisfaciendo las metas
y objetivos. Si se identifican problemas en el proceso de aseguramiento de
calidad, es responsabilidad del gestor aportarlos y aplicar los recursos
necesarios para resolver los conflictos de calidad.
- Costo de la calidad.
El costo de la calidad incluye todos
los costos que se generan o que demandan el desarrollo de las actividades
relacionadas con la calidad. Los estudios de costo de la calidad se llevan a
cabo para ofrecer una línea base e identificar oportunidades que reduzcan el
costo de calidad y proporcionan una base que sirva de comparación. La base de
normalización casi siempre es monetaria, ya que se tienen los datos necesarios
para evaluar dónde se encuentran las oportunidades para mejorar los procesos,
se puede evaluar el efecto de los cambios en términos monetarios. Los costos de
calidad se dividen en:
1) Costos asociados con prevención; estos costos incluyen la planificación de la calidad, revisiones técnicas formales, equipo de pruebas y entrenamiento.
2) Evaluación y fallas; estos costos incluyen actividades que permiten comprender mejor la condición del producto a través de cada proceso. Algunos ejemplos de costos de valuación incluye ni inspección en el proceso y procesos, calibración y mantenimiento de equipo además de las pruebas correspondientes. Los costos de fallas son aquellos que desaparecerán si no hubiese defectos antes de enviar el producto a los clientes. Estos costos se subdividen en costos de fallas internas y externas.
1) Costos asociados con prevención; estos costos incluyen la planificación de la calidad, revisiones técnicas formales, equipo de pruebas y entrenamiento.
2) Evaluación y fallas; estos costos incluyen actividades que permiten comprender mejor la condición del producto a través de cada proceso. Algunos ejemplos de costos de valuación incluye ni inspección en el proceso y procesos, calibración y mantenimiento de equipo además de las pruebas correspondientes. Los costos de fallas son aquellos que desaparecerán si no hubiese defectos antes de enviar el producto a los clientes. Estos costos se subdividen en costos de fallas internas y externas.
Se incurren los costos de fallas
internas cuando se detecta un defecto en el producto antes del envío, dichos
costos incluyen reelaboración, reparación y análisis el modo de falla. Los
costos de fallas externas se asocian con defectos detectados después de que el
producto ha sido enviado al cliente algunos ejemplos de estos son la resolución
de las quejas, devolución y reemplazo del producto, soporte de ayuda en línea y
trabajo de garantía.
- Garantía de la calidad del
software.
El control y la garantía de la calidad
son actividades esenciales en cualquier negocio que elabora productos de
consumo. En la actualidad, toda compañía tiene mecanismos que garantizan
la calidad en sus productos. De hecho, las afirmaciones explícitas de la
preocupación de una compañía por la calidad se ha convertido en una práctica de
mercadotecnia durante las décadas pasadas. La historia de la garantía de la
calidad en el desarrollo de software avanza paralelamente a la de la calidad en
la fabricación del hardware. Durante los primeros días de la computación
(décadas de 1950 y 1960), la calidad era responsabilidad exclusiva del
programado. Los estándares de garantía de la calidad para el software se
introdujeron en los contratos militares durante el decenio de 1970 y se han
extendido rápidamente en el desarrollo del software en el mundo de los
negocios.
Si se extiende la definición de
garantía de la calidad del software podemos decir que es un patrón de acciones
sistemático y planificado que se requiere para garantizar la alta calidad en el
software. Numerosos y diversos participantes tienen responsabilidad en la
garantía de la calidad del software como ingenieros de software, gestores del
proyecto, clientes, vendedores y los individuos que participan en el grupo de
desarrollo. Las revisiones del software son un filtro para el proceso de
software. Esto es, que las revisiones se aplican en varios puntos durante la
ingeniería del software y sirven para descubrir errores y defectos que pueden
eliminarse. La revisiones del software purifican las actividades que se han
denominado análisis, diseño y codificación. Freedman & Weinberg (1990),
abordan el modo siguiente y la necesidad de la revisiones:
" el trabajo técnico necesita
revisarse por la misma razón que los lápices necesitan gomas, errar es de
humanos. La segunda razón por la que se necesitan las revisiones técnicas es
que aunque la gente sea buena al captar algunos de sus propios errores, las
grandes clases de errores escapan de su creador con más facilidad de lo que se
le escapan a alguien más".
El objetivo principal de las revisiones
técnicas formales es descubrir los errores durante el proceso, de modo que no
se conviertan en defectos después de liberar el software. El beneficio de las
revisiones técnicas formales es el descubrimiento temprano de los errores de
modo que ya no se propaguen a la etapa siguiente en el proceso de desarrollo de
software.
De acuerdo a los estudios realizados por Vega et al (2008), algunas normativas de calidad en los sistemas de información y que ayudan a la realización, además de aplicar mejores prácticas en las organizaciones son:
De acuerdo a los estudios realizados por Vega et al (2008), algunas normativas de calidad en los sistemas de información y que ayudan a la realización, además de aplicar mejores prácticas en las organizaciones son:
- ISO 9000, gestión y
aseguramiento de calidad (conceptos y directrices generales).
- Recomendaciones externas
para aseguramiento de la calidad (ISO 9001, ISO 9002, ISO 9003).
- Recomendaciones externas
internas para aseguramiento de la calidad (ISO 9004).
- Malcom Baldridge national
quality award.
- Software Engineering
Institute (SEI).
- Capability Maturity Model
(CMM).
- Six Sigma.
Los sistemas ISO de garantía de calidad
fueron creados para ayudar a las organizaciones a garantizar que sus productos
y servicios satisfacen las expectativas de los clientes al cumplir las
especificaciones. El estándar ISO 9000 describe un sistema que garantiza la calidad
en términos genéricos y que se puede aplicar a cualquier negocio sin importar
los productos o servicios ofrecidos. ISO 9000 requiere que los sistemas de
operaciones de calidad y una compañía se sometan a revisión de auditores de una
tercera entidad, el cual tiene conocimiento del estándar y de su
funcionamiento. Antes del registro exitoso, los auditores extienden a la
compañía un certificado de la organización que representan. Entrevistas de
auditoría semianuales garantizan la concordancia continua con el estándar.
El estándar de garantía de la calidad
que se aplica en la ingeniería del software es el ISO 9001: 2000. Este estándar
contiene 20 requisitos que deben estar presentes para generar un sistema
eficiente de garantía de la calidad. Puesto que el estándar 9001: 2000 es
aplicable a todas las disciplinas de ingeniería, se ha desarrollado un conjunto
especial de directrices que permiten interpretar el estándar para emplearlo en
el proceso de software. Los requisitos que especifica el estándar abordan
tópicos como responsabilidad de la gestión, sistema de calidad, revisión de
contrato, control de diseño, control de documentos y datos, identificación y
seguimiento del producto, control de proceso, inspección y pruebas, acciones
correctivas y preventivas, control de registros de calidad, auditorías de
calidad interna, entrenamiento, servicio y técnicas estadísticas.
Una organización de software obtendrá
el registro ISO 9001:2000 si establece políticas y procedimientos para abordar
cada uno de los requisitos anotados además, ser capaz de demostrar que se
siguen dichas políticas y procedimientos.
Entre las políticas y procedimientos que se deben de demostrar en una auditoría están las siguientes:
Entre las políticas y procedimientos que se deben de demostrar en una auditoría están las siguientes:
a) Establecer los
elementos de un sistema de gestión de calidad
- Desarrollar, implementar y
mejorar el sistema.
- Definir una política
enfatice la importancia del sistema.
b) Documentar el
sistema de calidad
- Describir el proceso.
- Producir un manual
operativo.
- Desarrollar métodos para
controlar los documentos.
- Establecer métodos para la
conservación de registros.
c) Soporte del
control y la garantía de calidad
- Promover la importancia de
la calidad entre todos los participantes.
- Enfocarse en la satisfacción
del cliente.
- Definir un plan de calidad
que aborde objetivos, responsabilidades de autoridad.
- Definir mecanismos de
comunicación entre los participantes.
d) Establecer
mecanismos de revisión para el sistema de gestión de calidad
- Identificar métodos de
revisión y mecanismos de retroalimentación.
- Definir procedimientos de
seguimiento.
- Identificar recursos de
calidad que incluyan personal, entrenamiento, elementos de
infraestructura.
e) Establecer
mecanismos de control
- Para planeación.
- Para requisitos del cliente.
- Para actividades técnicas,
por ejemplo análisis diseño y pruebas.
- Para supervisión y gestión
del proyecto.
f) Definir métodos
para corrección
- Valorar los datos y métricas
de calidad.
- Definir enfoques para
procesos continuos y de mejora de la calidad.
Según Dunn y Ullman(1982), "el
aseguramiento de la calidad del software es el mapeo de los preceptos
gerenciales y las disciplinas de diseño de la garantía de calidad en el espacio
gerencial y tecnológico aplicable del ingeniería del software".
La habilidad para garantizar la calidad
es la medida de una disciplina de ingeniería madura. Cuando el mapeo se logra
de manera exitosa el resultado es la aplicación de la ingeniería de software en
un nivel de madurez.
2.12.1 Elementos que
permiten evaluar la calidad en el software
Según Juran (1992), la calidad, para
poder ser entendida de una mejor manera y posteriormente ser medida con
eficacia, debe ser expresada por medio de otros términos que tengan más sentido
para el usuario. En el caso del software. Estos factores son el medio por el
cual se traduce el término “calidad” al lenguaje de las personas que manejan la
tecnología.
Los factores de calidad que afectan a
la calidad del software se dividen en dos grandes grupos:
- Los que miden directamente
(defectos descubiertos en las pruebas).
- Los que se miden
directamente (facilidad de uso o de mantenimiento).
En cada caso debe presentarse una
medición. Se debe comparar el software con algún conjunto de datos y obtener
así algún indicio sobre la calidad. McCall, Richards & Walters (1977),
propusieron una clasificación de los factores que afectan directamente a la
calidad del software. Estos factores se muestran en la figura 2.30 En ella se
concentran tres aspectos importantes de un software:
- Características operativas.
- Capacidad para experimentar
cambios.
- Capacidad para adaptarse a nuevos
entornos.
A continuación se describen los
factores que propone McCall, Richards & Walters.
- Corrección.
El grado en que el programa cumple con
su especificación y satisfacer los objetivos que propuso el cliente.
- Confiabilidad.
El grado en que se esperaría que un
programa desempeña su función con la precisión requerida.
- Eficiencia.
La cantidad de código y de recursos de
cómputo necesarios para que un programa realice su función.
- Integridad.
El grado de control sobre el acceso al
software o los datos por parte de las personas no autorizadas.
- Facilidad de uso.
El esfuerzo necesario para aprender,
operar y preparar los datos de entrada de un programa interpretan la salida.
- Facilidad de mantenimiento.
El esfuerzo necesario para localizar y
corregir un error en un programa.
- Flexibilidad.
El esfuerzo que demanda probar un
programa con el fin de asegurar que realiza su función.
- Portabilidad.
El esfuerzo necesario para transferir
el programa de un entorno de hardware o software a otro.
- Facilidad de reutilización.
El grado en que un programa o partes de
él pueden reutilizarse en otras aplicaciones (en relación con el
empaquetamiento y el alcance de las funciones que realiza el programa).
- Interoperabilidad.
El esfuerzo necesario para acoplar un
sistema con otro.
Es difícil y en algunos casos
imposible, desarrollar medidas directas 1de
estos factores de la calidad. En realidad, muchas de las métricas que definen
McCall et al. Sólo se miden de forma subjetiva. Ya que es común que las
métricas adquieran la forma de una lista de comprobación que se emplea para
“asignar una graduación” a atributos específicos del software. Vega et al.
(2008), proponen un modelo con métricas distintas al propuesto por McCall y que
ha sido utilizado y comprobado en distintos proyectos de desarrollo de
software. Los factores que conforman al modelo y su descripción, se presentan a
continuación.
- Corrección.
El grado en que un producto de software
satisface sus especificaciones y consigue los objetivos de la misión
encomendada por el usuario.
- Confiabilidad.
El grado en que se puede esperar que un
producto de software lleve a cabo sus funciones esperadas con la precisión
requerida.
- Eficiencia.
La cantidad de recursos computacionales
y de código requeridos por un producto de software para llevar a cabo las
funciones encomendadas.
- Integridad.
El grado en que puede controlarse
(facilitar y restringir) el uso y acceso al software y a los datos, tanto al
personal autorizado como al no autorizado.
- Facilidad de uso.
El esfuerzo requerido para aprender,
trabajar, preparar la entrada e interpretar la salida de un producto de
software.
- Facilidad de mantenimiento.
El esfuerzo necesario para localizar y
corregir los errores en un producto de software.
- Flexibilidad.
El esfuerzo requerido para modificar un
producto de software una vez que se encuentra ya liberado o en producción, esto
es, una vez que el usuario esté haciendo uso de él.
- Facilidad de prueba.
El esfuerzo requerido para probar un
producto de software, de tal forma que se asegure que realiza las funciones
especificadas por el usuario.
- Portabilidad.
El esfuerzo requerido para transferir
un producto de software de una plataforma (entorno de hardware y software) a
otra.
- Reusabilidad.
El grado en que un producto de software
(o alguna de sus partes) pueda volver a ser utilizado en otras aplicaciones,
aún cuando la funcionalidad de la misma cambie.
- Facilidad de interoperación.
El esfuerzo requerido para lograr que
un producto de software trabaje con otro, compartiendo recursos.
MEDIDAS, MÉTRICAS E
INDICADORES
La medición asigna números o símbolos a
atributos de entidades reales. Esto requiere un modelo de medición que abarque
un conjunto existente de reglas. En el contexto de la ingeniería del software
una medida proporciona una indicación cuantitativa de la extensión, la
cantidad, la dimensión, la capacidad o el tamaño de algún atributo de un
producto o proceso. La medición ocurre como resultado de la recopilación de uno
o más puntos de datos. Una métrica de software relaciona de alguna manera las
medidas individuales, de igual manera un ingeniero de software recopila medidas
y desarrolla métricas para obtener los indicadores.
Un indicador es una métrica o una
combinación de métricas que proporcionan conocimientos acerca del proceso del
desarrollo de software, un proyecto de software o el propio producto. Un
indicador proporciona conocimientos que permiten a los ingenieros de software
ajustar el proceso, el proyecto o el producto para que las cosas mejoren.
Existe la necesidad de medir y controlar la complejidad en el desarrollo del
software, debe de tenerse la posibilidad de desarrollar medidas de diferentes
atributos internos del programa. Estas medidas y las métricas derivadas de
ellas se utilizan como indicadores independientes de la calidad de los modelos
de análisis y diseño.
Antes de generar e introducir una serie
de métricas del producto debemos contemplar que se:
- Deben de ayudar a evaluar
los modelos de análisis y diseño.
- Deben ofrecer una indicación
de la complejidad de los diseños procedimentales y el código fuente.
3) Deben de facilitar el diseño de
pruebas más efectivas.
Es importante comprender los principios
básicos de la medición. Según Roche (1994), sugiere un proceso de medición en
el que se caracterizan cinco actividades primordiales las cuales son:
1) Formulación. La derivación de medidas y métricas apropiadas para la representación del software que se considera.
1) Formulación. La derivación de medidas y métricas apropiadas para la representación del software que se considera.
2) Recolección. El mecanismo con que se
acumulan los datos necesarios para derivar las métricas formuladas.
3) Análisis. El cálculo de las métricas
y la aplicación de herramientas matemáticas.
4) Interpretación. La evaluación de las
métricas en un esfuerzo por conocer mejor la calidad de la representación.
5) Retroalimentación. Recomendaciones
derivadas de la interpretación de las métricas del producto transmitidas al
equipo del software.
Las métricas del software sólo serán
útiles si están caracterizadas de manera efectiva y se validan para probar su
valor. Según Lethbridge (2003), los siguientes principios son representativos
de muchos otros que podrían proponerse para caracterizar y validar las
métricas. Una métrica debe tener propiedades matemáticas deseables. Es decir,
el valor de la métrica debe estar en un rango significativo por ejemplo, de
cero a uno, donde cero realmente significa ausencia, uno indica el valor máximo
y 0.5 representa el punto medio. Además, una métrica pretende estar en una
escala racional no debe contar con componentes que sólo se miden en una escala
ordinal. Cuando una métrica representa una característica de software que
aumenta cuando se presentan rasgos positivos o que disminuya al encontrar
rasgos indeseables, el valor de la métrica debe aumentar o disminuir en el
mismo sentido.
Cada métrica debe validarse
empíricamente en una amplia variedad de contextos antes de publicarse o
aplicarse la toma de decisiones. Una métrica debe medir el factor de interés,
independientemente de otros factores. Debe crecer para aplicarse a sistemas
grandes y funcionar en diversos lenguajes de programación y dominios de
sistemas. Aunque la formulación, caracterización y validación son críticas, la
recopilación y el análisis son las actividades que dirigen el proceso de medición.
Roche(1994) sugiere las siguientes directrices para estas actividades:
1) Siempre que sea
posible deben automatizarse la recopilación de datos y su análisis.
2) Deben aplicarse
técnicas estadísticas válidas para establecer relaciones entre los atributos internos
del producto y las características externas de la calidad.
3) Para cada métrica
deben establecerse directrices y recomendaciones para la interpretación.
Se han propuesto cientos de métricas
para el desarrollo de software pero no todas proporcionan un soporte práctico
para el ingeniero de software. Algunas exigen mediciones demasiado complejas
otras son demasiado especializadas que pocos profesionales podrían
comprenderlas y otras más violan las nociones básicas de lo que es el software
de alta calidad. Ejiogu (1991), define un conjunto de atributos que toda
métrica efectiva del software debe abarcar. La métrica derivada y las medidas
que llevan a ella deben ser:
- Simples incalculables. Debe
ser relativamente fácil aprender a derivar la métrica y su cálculo no debe
exigir cantidades anormales de tiempo o esfuerzo.
- Empírica e intuitivamente
persuasivas. La métrica debe satisfacer las nociones intuitivas del
ingeniero acerca del atributo del producto que se está construyendo.
- Consistentes y objetivas. La
métrica siempre debe arrojar resultados que no permitan ambigüedad alguna.
- Consistentes en el uso de
unidades y dimensiones. El cálculo matemático de la métrica debe emplear
medidas que no lleven a combinaciones extrañas de unidades.
- Independientes del lenguaje
de programación. Las métricas deben basarse en el modelo de análisis o
diseño o en la estructura del propio programa.
- Mecanismos efectivos para la
retroalimentación de alta calidad. Es decir, la métrica debe llevar a un
producto final de la más alta calidad.
Aunque casi todas las métricas de
software satisfacen esos atributos, algunas métricas de uso común no cumplen
con una o dos de ellas. Aunque se ha propuesto una amplia variedad de taxonomía
en métricas, el siguiente esquema atiende a las cuatro más importantes en el
desarrollo del software.
- Métricas para el modelo de
análisis. Estas métricas atienden varios aspectos de la etapa de análisis en
donde se incluyen:
- Funcionalidad entregada.
Proporciona una medida indirecta de la funcionalidad que se empaqueta con
el software.
- Tamaño del sistema. Mide el
tamaño general del sistema, definido desde el punto de vista de la
información disponible como parte del modelo de análisis.
- Calidad de la
especificación. Proporciona un indicador específico o el grado en que se
ha completado la especificación de los requisitos.
- Métricas para el modelo de
diseño. Estas
métricas cuantifican los atributos del diseño de manera tal que le
permiten al ingeniero de software evaluar la calidad del diseño, la
métrica incluye:
- Métricas arquitectónicas.
Proporcionan un indicio de la calidad del diseño arquitectónico.
- Métricas al nivel de
componente. Mide la complejidad de los componentes del software y otras
características que impactan la calidad.
- Métricas de diseño de la
interfaz. Se concentran principalmente en la facilidad de uso.
- Métricas especializadas en
diseño orientado a objetos. Miden características de clases, además de
las correspondientes a comunicación y colaboración.
- Métricas para el código
fuente. Estas
métricas miden el código fuente y se usan para evaluar su complejidad,
además de la facilidad con que se mantiene y prueba entre otras
características como:
- Métricas de complejidad.
Miden la complejidad lógica del código fuente.
- Métricas de longitud.
Proporcionan un indicio del tamaño del software.
- Métricas para pruebas. Estas métricas ayudan
a diseñar casos de prueba efectivos y evaluar la eficacia de las pruebas
en donde se incluyen:
- Métricas de cobertura de
instrucciones y ramas. Lleva al diseño de casos de prueba que
proporcionan cobertura del programa.
- Métricas relacionadas con
los defectos. Se concentran en encontrar defectos y no en las propias
pruebas.
- Efectividad de la prueba.
Proporciona un indicio en tiempo real de la efectividad y de las pruebas
aplicadas.
- Métricas en el proceso. Métricas
relacionadas con el proceso de las pruebas.
En muchos casos las métricas de un
modelo pueden aplicarse en actividades posteriores de la ingeniería del
software. Por ejemplo, las métricas de diseño se utilizan para estimar el esfuerzo
requerido para generar código fuente.
Conclusión
El éxito en la producción
de software se obtiene logrando hacerlo con calidad y demostrando el grado de
ésta, calificando como buena. Esto sólo es posible con la implantación de un
Sistema para el Aseguramiento de la Calidad del Software directamente
relacionado con la política establecida para su elaboración y que esté en
correspondencia con la definición internacional ISO de calidad, ampliamente
aceptada, y por los estándares del grupo ISO 9000.
Fuentes de consultas:
Anónimo. "Sistemas de gestión de calidad:
ISO 9001". Cursos gratis. http://www.mailxmail.com/curso/empresa/iso9001/capitulo1.htm
Cueva Lovelle, Juan Manuel. "Calidad del
Software". Universidad de Oviedo, España. 1999.
Febles Estrada, Ailyn. "Calidad de
software". Maestría de Informática Aplicada, Universidad de Matanzas
"Camilo Cienfuegos", 2006.
Vídeo Norma ISO/IEC 9126 y Métrica de Calidad del Software
Norma ISO/IEC 14598
y Tipos de Pruebas de Software
Norma
ISO/IEC
25000 y Modelos
para Evaluar la Calidad del Software
0 comentarios: