Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Caractersticas: Se afirma que para que las mtricas sean tiles ests deben
tener las siguientes cuatro caractersticas:
1. Cuantificables, deben basarse en hechos, no en opiniones.
2. Independientes, los recursos no deben poder ser alterados por los miembros
que las apliquen o utilicen.
3. Explicable, debe documentarse informacin acerca de la mtrica y de su uso.
4. Precisas, debe de conocerse un nivel de tolerancia permitido cuando se mide.
Mtricas del producto
Para justificar la existencia de este tipo de mtrica, se argumenta que stas deben
ser enunciadas y utilizadas para administrar el proceso de desarrollo y debe ser
conforme al producto de software particular. El proveedor de productos de
software debe de recopilar y actuar sobre las medidas cuantitativas de la calidad
de esos productos de software.
Estas medidas deben ser utilizadas para los siguientes propsitos:
1. Para recopilar informacin y reportar valores de mtricas sobre bases regulares.
2. Para identificar el actual nivel de desempeo por cada mtrica.
3. Para tomar la accin remedial si los niveles de las mtricas crecen peor o
exceden los niveles objetivos establecidos.
4. Para establecer metas de mejoras especificas en trminos de las mismas
mtricas.
Mtricas de proceso
El proveedor debe tener mtricas cuantitativas de la calidad del proceso de
desarrollo y de liberacin. Estas mtricas deben de reflejar:
a) Qu tan bien el proceso de desarrollo est siendo llevado a cabo en trminos
de puntos de revisin y en objetivos de calidad en el proceso, siendo cumplidos en
tiempo de calendario.
b) Qu tan efectivo es el proceso de desarrollo, al reducir la probabilidad que se
introduzcan fallas o que cualquier falla introducida sea detectada.
Aqu como las partes de las mtricas del producto, lo importante es que los niveles
sean conocidos y utilizados, para el control del proceso y de las mejoras, y no
cinco
niveles,
Proceso Inicial (Nivel 1): Su objetivo es formar una base de comparacin con la
forma en que las mejoras se realicen y se incremente la madurez, estos incluyen:
a) El tamao del producto,
b) El esfuerzo del personal (Utilidades para determinar una tasa de productividad)
Proceso Repetible (Nivel 2): Las mtricas a este segundo nivel incluyen como
objetivos de medicin los siguientes:
1. La cantidad de esfuerzo necesaria para desarrollar un sistema,
2. La duracin del proyecto,
3. El tamao y la volatilidad de los requerimientos,
4. El costo global del proyecto (Por lo que el tipo de mtrica que se recomiendan
incluye a las siguientes):
a) Tamao del software (Lneas de codillo fuente no comentadas).
b) Puntos de Funcin.
c) Cuenta de objetos y mtodos.
5. Esfuerzo del trabajo de personal:
a) Esfuerzo real medido en unidades persona/mes.
b) Esfuerzo reportado en unidades persona/mes.
6. Volatilidad de los requerimientos (Cambios de los requerimientos).
ingles), ya que ayuda a asegurar que el producto cumpla con los requisitos; sin
embargo las pruebas de software no son QA, tan solo son una parte de ella.
La industria del software a travs de su historia ha encontrado la necesidad de
refinar aspectos fundamentales vinculados directamente a su proceso productivo:
1. Los costos y el tiempo: la dificultad de planear proyectos de software trae
consigo problemas en la estimacin de tiempos y por ende altos costos asociados;
la creacin de mtricas de software y procesos de planeacin eficientes han
ayudado a amortiguar el peso de stos factores en el desarrollo del software.
2. La calidad: debido a la competitividad del mercado de software la calidad se
convierte en un factor determinante a la hora de comercializar los productos.
Igualmente, permite disminuir los tiempos de mantenimiento al obtener productos
con menor cantidad de errores inyectados y por ende ms confiables.
La importancia de las pruebas de software se puede visualizar teniendo como
referencia algunos autores:
- Las pruebas de software permiten pasar de forma confiable del cmodo
ambiente planteado por la ingeniera de software, es decir del controlado ambiente
de anlisis, diseo y construccin, al exigente mundo real en el cual los entornos
de produccin someten los productos a todo tipo de fatiga.
- Las pruebas de software basadas en componentes permite la reutilizacin y por
ende la reduccin de los ciclos de pruebas, lo cual se ve reflejado en la
disminucin de costos y tiempos.
- La necesidad de productos de software de alta calidad ha obligado a identificar y
cuantificar factores de calidad como: capacidad de uso, capacidad de prueba,
capacidad de mantenimiento, capacidad de ser medible, capacidad de ser
confiable y a desarrollar practicas de ingeniera que contribuyen a la obtencin de
productos de alta calidad.
Taxonoma de las Pruebas en aplicaciones de Software
Las pruebas de software se tipifican de acuerdo a los aspectos especficos que se
van a probar en el software. En la literatura existen diversos autores que proponen
taxonomas caracterizadas por su grado de profundidad o expansin.
La clasificacin propuesta por Burnstein se caracteriza por ser una
taxonoma generalizada, enfocada en tipos de pruebas tpicos en la industria del
software. La clasificacin incluye pruebas de: funcionalidad, de rendimiento, de
fatiga, de configuracin, de seguridad y de recuperacin.
Por otro lado existen taxonomas que buscan abarcar un conjunto de aspectos
ms amplio en las pruebas, lo cual conduce a que stas contengan una expansin
notable en la cantidad de tipos, ofreciendo una visin ms detallada del horizonte
de pruebas e influyendo positivamente en todo el proceso de pruebas. Myers
clasifica los tipos de pruebas en: de locacin, de volumen, de fatiga, de capacidad
de uso, de seguridad, de rendimiento, de almacenamiento, de configuracin, de
compatibilidad y conversin, de instalacin, de capacidad de ser confiable, de
recuperacin, de utilidad, de documentacin, de procedimientos y de aceptacin.
Las tcnicas de pruebas de software constituyen un mecanismo conceptual
mediante el cual se pueden detectar defectos en el software. En la taxonoma
citada por Young y Taylor, se puede observar que se tipifican las tcnicas de
pruebas de software teniendo en cuenta el ciclo de desarrollo del mismo y su
estado (caracterstica estticas o dinmicas).
Existen otras tcnicas no clasificadas segn su estado; es el caso de las citadas
por Burnstein as:
1. Pruebas de tipo aleatorio: se generan los valores correspondientes a los
casos de pruebas de forma aleatoria teniendo en cuenta la especificacin de las
entradas y en algunos casos las salidas. Algunos autores proponen tcnicas de
muestreo aleatorio con restricciones que permiten reducir la poblacin objetivo sin
afectar los hallazgos de defectos.
2. Pruebas de particin de clases equivalentes: La poblacin de entrada se
generan a partir del muestreo de conjuntos de valores llamados clases. Las clases
seleccionadas deben cubrir todo el dominio de valores de entrada o salida y no
deben traslaparse. Aunque existe una dificultad asociada en el diseo de pruebas
usando esta tcnica, la probabilidad de hallar defectos es bastante alta adems
elimina la necesidad de realizar pruebas exhaustivas.
3. Pruebas de valores lmite: Partiendo de la prueba de particin de clases
equivalentes se puede incorporar en los datos de pruebas, valores limites de las
clases particionadas, es decir, valores que se encuentran en el borde de una u
otra clase. Cuando se prueban los valores limites, la probabilidad de encontrar
defectos aumenta, dado que estos puntos son los ms susceptibles de contener
errores.
4. Pruebas de suposicin de error: La forma ms intuitiva de seleccionar valores
de prueba es a travs de la suposicin de errores la cual se basa en la experiencia
del diseador de pruebas. Esta tcnica pretende revelar defectos cuando se elijen
valores del dominio de entrada que producen determinados valores del dominio de
salida.
5. Pruebas de transicin de estados: Esta tcnica se basa en el diagrama de
transicin de estados construido para los objetos relevantes del sistema. El
diagrama de transicin de estados presenta los diferentes estados de un objeto y
los eventos que generan las transiciones. Cuando un diseador de casos de
prueba utiliza una tcnica de transicin de estados tabula las combinaciones
posibles que deben ocurrir para que un objeto pase de un estado a otro. Esta
informacin de secuencia de eventos es utilizada por el probador para buscar
falencias en los estados y sus transiciones.