Deprecated: Function eregi() is deprecated in http://elblogdelprofesto.blogspot.com/ on line 3

CALIDAD DEL SOFTWARE


Calidad: Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor.

Software: Conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora.

ISO: siglas de International Organisation for Standardization, Organización Internacional de Normalización, organismo encargado de coordinar y unificar las normas nacionales. En 1926, 22 países se reunieron para fundar una federación internacional de los comités nacionales de normalización, la ISA (International Standardizing Associations). Este organismo fue sustituido en 1947 por la ISO, cuya sede está situada en Ginebra. Cada país miembro está representado por uno de sus institutos de normalización, y se compromete a respetar las reglas establecidas por la ISO relativas al conjunto de las normas nacionales. Esta institución tiene por tarea desarrollar la normalización con carácter mundial y, a tal efecto, pública normas internacionales conocidas como "normas ISO", que intentan acercar las normas nacionales de cada Estado miembro. La ISO es un organismo consultivo de las Naciones Unidas.



Las ventajas de implantar un sistema de gestión de la calidad son las siguientes:

1. Aumento de beneficios.
2. Aumento del número de clientes.
3. Motivación del personal.
4. Fidelidad de los clientes.
5. Organización del trabajo.
6. Mejora de las relaciones con los clientes.
7. Reducción de costes debidos a la mala calidad.
8. Aumento de la cuota de mercado.


Los factores de la calidad del software y los defectos
Originalmente, la calidad de un programa o sistema se evaluaba de acuerdo al número de defectos por cada mil líneas de código.

En 1988, un estudio realizado en los EEUU, demostró que se introducían cerca de sesenta defectos por cada mil líneas de código (60 def/KLOC), hoy se le adicionan otros factores a la calidad del software.

Los factores que determinan la calidad del software se clasifican en tres grupos:

1. Operaciones del producto: características operativas

2. Corrección: Grado en que un programa satisface sus especificación y logra los objetivos marcados por el usuario. (¿Hace lo que se le pide?).

3. Fiabilidad: Grado en que se puede esperar que un programa lleve a cabo las funciones esperadas con la precisión requerida. (¿Lo hace de forma fiable todo el tiempo?).

4. Eficiencia: Cantidad de recursos de computadoras y de código requeridos por el programa para realizar sus funciones con los tiempos de respuesta adecuados. (¿Qué recursos hardware y software necesito?).

5. Integridad: Grado en que puede controlarse el acceso al software o a los datos por usuarios no autorizados. (¿Puedo controlar su uso?).

6. Facilidad de uso: Esfuerzo necesario para aprender, utilizar, preparar las entradas e interpretar las salidas de un programa. (¿Es fácil y cómodo de manejar?).

7.Revisión del producto: capacidad para soportar cambios.

8. Facilidad de mantenimiento: Esfuerzo requerido para localizar y arreglar un error en un programa. (¿Puedo localizar los fallos?).

9. Flexibilidad: Esfuerzo requerido para modificar un programa. (¿Puedo añadir nuevas opciones?).

10. Facilidad de prueba: Esfuerzo requerido para probar un programa de forma que se asegure que realiza la función requerida. (¿Puedo probar todas las opciones?).
Transición del producto: adaptabilidad a nuevos entornos.

11. Portabilidad: Esfuerzo requerido para transferir un programa desde un entorno HW y/o SW a otro. (¿Podré usarlo en otra máquina?).

12. Reusabilidad: Grado en que un programa o componente SW se puede reutilizar en otras aplicaciones. (¿Podré utilizar alguna parte del software en otra aplicación?).

13. Interoperatividad: Esfuerzo requerido para acoplar un sistema con otras aplicaciones o sistemas. (¿Podrá comunicarse con otras aplicaciones o sistemas informáticos?).

Métricas de la calidad software

Es difícil, y en algunos casos, imposible, desarrollar medidas directas de los factores de calidad del software. Cada factor de calidad Fc se puede obtener como combinación de una o varias métricas:

Fc= c1 * m1 + c2 * m2 + … + cn * mn

Ci: factor de ponderación de la métrica i, que dependerá de cada aplicación específica.

mi: métrica i.

(Habitualmente se puntúan de 0 a 10 en las métricas y en los factores de calidad).

Métricas para determinar los factores de calidad:

a. Facilidad de auditoria.
b. Exactitud.
c. Normalización de las comunicaciones.
d. Completitud.
e. Concisión.
f. Consistencia.
g. Estandarización de los datos.
h. Tolerancia de errores.
i. Eficiencia de la ejecución.
j. Facilidad de expansión.
k. Generalidad.
l. Independencia del hardware.
m. Instrumentación.
n. Modularidad.
ñ. Facilidad de operación.
o. Seguridad.
p. Autodocumentación.
q. Simplicidad.
r. Independencia del sistema software.
s. Facilidad de traza.
t. Formación.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

PLAN DE PRUEBAS DE SOFTWARE


El Plan de Pruebas
El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas.
Note que puede haber un plan global que explicite el énfasis a realizar sobre los distintos tipos de pruebas (verificación, integración e integración).

Un plan de pruebas incluye:

1. Identificador del plan.
Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance, por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de verificación del requerimiento 1 de seguridad), TP-Contr-X (plan de verificación del contrato asociado al evento de sistema X), TP-Unit-Despachador.iniciar (plan de prueba unitario para el método iniciar de la clase Despachador). Como todo artefacto del desarrollo, está sujeto a control de configuración, por lo que debe distinguirse adicionalmente la versión y fecha del plan.

2. Alcance
Indica el tipo de prueba y las propiedades/elementos del software a ser probado.

3. Items a probar
Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es dificil y riesgoso probar una configuración que aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén perfectos, puede que detectemos fallas graves demasiado tarde.

4. Estrategia
Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la precondición" o "Ejercicio de los caminos ciclomáticos válidos". En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar, por ej. 100% de las fronteras, 60% de los caminos ciclomáticos... La estrategia también explicita el grado de automatización que se exigirá, tanto para la generación de casos de prueba como para su ejecución.

5. Categorización de la configuración
Explicita las condiciones bajo las cuales, el plan debe ser:
Suspendido,
Repetido;
Culminado.
En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Al corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe explicitarse a partir de qué punto, ya que puede ser necesario repetir algunas pruebas. Los criterios de culminación pueden ser tan simples como aprobar el número mínimo de casos de prueba diseñados o tan complejo como tomar en cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas y la tasa de detección de fallas.

6. Tangibles
Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej. subplanes, especificación de pruebas, casos de prueba, resumen gerencial del proceso y bitácora de pruebas.

7. Procedimientos especiales
Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiere.

8. Recursos
Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas (p. ej. el sistema de operación), cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación específica del software a probar (p. ej. qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo.
La sección incluye un estimado de los recursos humanos necesarios para el proceso. También se indican cualquier requerimiento especial del proceso: actualización de licencias, espacio de oficina, tiempo en la máquina de producción, seguridad.


9. Calendario
Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar.

10. Manejo de riesgos
Explicita los riesgos del plan, las acciones mitigantes y de contigencia.

11. Responsables
Especifica quién es el responsable de cada una de las tareas previstas en el plan.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Metodología para Requisitos del Sistema

Les dejo un metodología para la obtención y presentación de reportes para los requisitos del sistema.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS