Métricas de calidad. El concepto de métrica es el termino que describe muchos y muy variados casos de medición. Siendo una métrica una medida estadística (no cuantitativa como en otras disciplinas ejemplo física) que se aplica a todos los aspectos de calidad de software, los cuales deben ser medidos desde diferentes puntos de vista como el análisis, construcción, funcional, documentación, métodos, proceso, usuario, entre otros.

1. Facilidad de operación.

• Mucho procesamiento matemático y lógico
• Procesamiento complejo de las entradas
• Procesamiento complejo de las salidas
• Muchas excepciones de procesamiento, muchas transacciones incompletas y mucho procesamiento de las transacciones.
• Procesamiento de seguridad y/o control sensitivo.

• Medidas del software según el análisis, el propósito es evaluar el conjunto de primitivas, es decir los elementos más bajos del análisis que no se pueden subdividir más.

• Primitivas funcionales (PFu) – Nivel inferior
• Elementos de datos (ED) – Atributos de objetos
• Objetos (OB) – Objetos de datos
• Relaciones (RE) – Conexiones entre objetos de datos
• Estados (ES) – Estados – Diagrama de transición
• Transiciones (TR) – Número de transacciones – Diagrama de transición.

• Primitivas modificadas de función manual (PMFu), funciones externas que modifican para adaptarse al nuevo sistema.

• Elementos de datos de entrada (EDE) – Introduce al sistema
• Elementos de datos de salida (EDS) – Datos que saca el sistema
• Elementos de datos retenidos (EDR) – Datos almacenados
• Muestras (tokens) datos (TCi) – Elementos que existen en la línea X. token por primitiva. Símbolos léxicos diferentes visibles en cada primitiva.
• Conexiones relación (REi) – conexiones entre objetos

• Métricas de calidad de especificación, valoran y modelan los requisitos.

• Métricas de diseño

• Complejidad estructural, S(i) = Fout ² (i), siendo Fout(i) la expansión del módulo (i), definiendo expansión como la cantidad de módulos inmediatamente subordinados al módulo i, o como el número de módulos invocados por el módulo i.
• Complejidad de los datos, D(i) = V(i) / [Fout(i) + 1], siendo V(i) el número de variables de entrada y salida del módulo (i).
• Complejidad del sistema, C(i) = S(i) + D(i)

• El valor comercial de un sistema para el usuario
• Tamaño del proyecto, costo y tiempo de desarrollo
• Calidad y productividad del programados
• Esfuerzo de adaptación, modificación y mantenimiento
• Posibilidad de desarrollo propio
• Beneficios de implementación en 4GL

1. Se identifican las funciones disponibles para el usuario y se organizan en cinco grupos así :

• Salidas
• Consultas
• Entradas
• Archivos
• Interfaces

1. Se ajusta este total de acuerdo con unas características del entorno.

1. Tiene formato diferente
2. Tiene el mismo formato que otra salida pero requiere diferente lógica de procesamiento.

• Archivo de transacción enviado a otra aplicación
• Facturas
• Cheques
• Fichas perforadas
• Transacciones automáticas
• Mensajes al usuario
• Cintas
• Gráficos
• Archivos de Back-Up, entro otros.

• Cabeceras de columnas, títulos, números de página
• Mensajes individuales (información, confirmación o respuestas a consultas de error)
• Salida en igual formato y lógica que ya se haya contado para otro soporte (procesos anidados).

1. Tiene un formato diferente
2. Tiene el mismo formato que otra entrada pero requiere una lógica diferente de procesamiento, o se modifica un archivo interno lógica diferente.

• El ratón
• Documentos
• Transacciones de cintas
• Pantallas sensitivas
• Lectores de código de barras, etc

1. Tienen un formato diferente de otras, bien en su entrada o salida.
2. Tienen el mismo formato, tanto entrada como salida, que otra consulta, pero requiere diferente lógica de procesamiento en cualquiera de las dos.

1. Utiliza claves simples para recuperar datos específicos – esto es , un registro simple o grupo de registros, no un rango –
2. Requiere respuesta inmediata
3. No realiza funciones de actualización (aunque se pueden efectuar calculos)

• Consultas de usuario/pantalla sin actualización de archivos u otra entidad lógica.
• Archivos de transacción que salen del límite de la aplicación si está accesible al usuario on-line.
• Pantalla de selección de menú (todas las pantallas de menú cuentan como una consulta)
• Mensajes de información o pantallas de ayuda.

• Bases de datos : uno por cada vista lógica o camino de acceso
• Archivos maestros : uno por cada grupo de claves
• Tablas mantenidas por los usuarios : estados, tarifas, mensajes, etc.
• Archivos de procesamiento batch
• Índices de referencias cruzadas

1. Datos o información de control se pasa del archivo A al archivo B. En A se indica como archivo e interfaz y en B sólo como interfaz.
2. Datos o información de control se pasa del archivo B a A. En b se indica como archivo e interfaz y en A sólo interfaz.
3. Datos o información de control se comparte entre A y B. A y B reciben puntos de archivo e interfaces.

• Archivos lógicos internos accesibles desde otra aplicación
• Archivos lógicos internos accesibles en otra aplicación
• Bases de datos compartidas
• Lista de parámetros compartida
• Archivos de impresión exportados
• Archivos de transacción compartidos que requiere conversión

• Archivo de registros de otra aplicación – en la otra aplicación (+1 archivo. +1 interfaz)

Esta característica se asocia con dos procesos asociados con el ciclo de vida del software llamados la implantación y control del sistema.

• Construcción del nuevo sistema
• La entrega del nuevo sistema

• Propósitos y objetivos
• Tareas y actividades a realizarse
• Secuencia y solapamiento de actividades
• Técnicas usadas
• Técnicas para completar las fases
• Manejo del tiempo invertido

• Actividad 1. Red. Es primordial determinar las necesidades y sus detalles. Es necesario : La validación de dispositivos, velocidad de transmisión, topología, diseño del sistema eléctrico, seguridad, respaldo, protocolos, medios de transmisión a utilizar.
• Actividad 2. Bases de datos. Es primordial determinar los esquemas y sus detalles (estructuras de archivos), tener en cuenta las características de los sistemas distribuidos. En este caso es necesario se determinen los elementos compartidos de mayor estabilidad en el sistema, estos son los datos, a los cuales es necesario verificarles : Equipos de hardware donde estará implantado, herramienta de software requerida, validación del sistema operativo, manejador de base de datos (SGDB), software de comunicaciones. En forma adicional de la base se verifican archivos lógicos y físicos, la producción de la base de datos, interfaces con otros sistemas o bases de datos, además de verificar los diccionarios de datos y flujos. Estos entre otros elementos que sean considerados con base en las necesidades y características del sistema.

• Actividad 1. Plan de programación. Es este se incluyen tres etapas, en las cuales se ve involucrada la toma de decisiones por parte del personal responsable es decir los programadores.

• Etapa 1. Revisión del diseño. Al realizar esta actividad de garantía en el proceso de desarrollo, los diseñadores toman la decisión de congelar los diseños realizados, ya que con estos los programadores inician el trabajo de generación del código en lenguajes de programación, esta acción de congelar se hace para que no existan mejoras posteriores que obliguen a una retroalimentación del proceso y sea necesario extender los tiempos definidos en el cronograma.
• Etapa 2. Organización del equipo de programación. Es importante recordar que los jefes de equipo no son estables, esto se presenta cuando existe suficiente personal. Ahora ¿qué ocurre cuando no existe suficiente personal en la organización?. Se plantean dos elementos importantes a ser evaluados : La existencia de suficiente personal permite que este sea distribuido según las necesidades y conocimientos; al no existir suficiente personal es necesario determinar las características del cronograma y como se resuelven las necesidades según el sistema a desarrollar.
• Etapa 3. Plan de programación detallado. Es necesario sea asignado el personal, o se definan un cronograma adecuado. Para este caso es necesario se asuman políticas de trabajo como :
• Uso de versiones del programa
• Procesos o actividades en orden de importancia
• Normas de programación (estándares)
• Datos de prueba.

• Actividad 2. Escribir y probar programas. En esta actividad se determinan :

• Componentes a ser reutilizables.
• Documentación de los programas (Revisiones)
• Recomendaciones y requisitos de calidad

• Individuales – programas, subrutinas, bloques, ..
• Unidades o programas – Módulos
• Sistema – Integración, donde la salida de unos es la entrada de otros.

• Actividad 1. Instalación y prueba del sistema. Es necesario se haga el ejercicio mental, acerca de si la solución acerca del sistema de información fue desarrollado o comprado, esto ya que es necesaria la actualización de bibliotecas y documentación propias de la empresa que será la beneficiaría del sistema, además estas entregas deben estar dilucidadas en el contrato del desarrollo del proyecto, es importante que las especificaciones correspondan con un estándar el cual debe estar definido.
• Actividad 2. Integración. Este numeral aparece en dos casos : Las necesidades de integración y la documentación del programa. Es necesario se evalúen los posibles casos que se presentan, como existencia de sistemas anteriores, montaje y ejecución en maquinas de bajo desempeño, posibles casos de error y sus respuestas. En caso de ser comprado, validar la adaptación e integración a las necesidades de la empresa.
• Actividad 3. Prueba completa. El caso a ser verificado es la necesidad que el sistema funcione como un conjunto, a través de un grupo de datos de prueba seleccionados y determinados tanto en el diseño como en la codificación.
• Actividad 4. Conversión y entrega. En este caso es necesario se garantices las conversiones de bases de datos, archivos y todos los elementos físicos y lógicos de manejo de información, Generalmente este caso se presenta al convertir sistemas antiguos a nuevos.

• Actividad 1. Instalar archivos y base de datos. Es necesario existan o se desarrollen las interfaces de conversión de archivos y bases de datos. Evaluando el tiempo de conversión y las necesidades de información de los puestos de trabajo.
• Actividad 2. Capacitación. Para este caso es necesario tener presente : Documentación apropiada, Manuales de usuario, Capacitación o formación del usuario final. Es importante recordar que el usuario final es un actor que se encuentra involucrado desde el inicio del desarrollo del proyecto, en cual el se sentirá comprometido con el proyecto y parte de él.

• Actividad 3. Conversión. Para este paso se plantean las siguientes estrategias :

Finalmente y como recomendación, para cualquier trabajo de desarrollo de sistemas que pretenda solucionar problemas de procesamiento y transmisión de datos e información, es necesario que estos sean desarrollados bajo las características técnicas y de aseguramiento de la calidad de entidades internacionales como ISO, IEEE, ITU.

Título - Normas de gestión de la calidad y garantía de la calidad

Parte 3 - Orientaciones para la aplicación de la Norma ISO 9001 al desarrollo, suministro y mantenimiento del software

Naturaleza - Norma internacional

Ámbito - Desarrollo de Sistemas de Información. Procesos del ciclo de vida. Calidad del software.

Esta parte de la ISO 9000 contiene orientaciones que facilitan la aplicación de la Norma ISO 9001 a las organizaciones dedicadas al desarrollo, suministro y mantenimiento del software.

Se pretende con ella dar orientaciones en relación con situaciones en las que un contrato entre dos partes exija la demostración de la capacidad de determinado proveedor para desarrollar, suministrar y mantener productos de software.

Tales orientaciones describen las clases de control y los métodos sugeridos para la producción del software, que satisfagan los requisitos establecidos. Esto será posible principalmente a través de la prevención de "no-conforme" a lo largo de todas las fases del proceso, desde el desarrollo hasta el mantenimiento.

• Sistema de la calidad – estructura.
• Responsabilidad de la gestión.
• Sistema de la calidad.
• Auditorías internas al sistema de la calidad.
• Acciones correctivas.
• Sistema de la calidad - actividades a lo largo del ciclo de vida.
• General.
• Análisis del contrato.
• Especificación de los requisitos del comprador.
• Planificación del desarrollo.
• Planificación de la calidad.
• Proyecto e implementación.
• Pruebas y validaciones.
• Aceptación.
• Reproducción, entrega e instalación
• Mantenimiento.
• Sistema de la calidad - actividades de apoyo (independientes de cualquier fase)
• Gestión de la configuración
• Control de documentos
• Registros de la calidad
• Medición
• Reglas, prácticas y convenciones
• Herramientas y técnicas
• Aprovisionamiento
• Productos de software incluidos

ISO 8402: 1994, Gestión y garantía de la calidad – vocabulario.

Desde que la ISO 9001 fue escrita para ser utilizada por toda clase de industrias, es regularmente difícil interpretarla para el desarrollo de software, por lo cual se publicó la ISO 9000-3 "Guía para la aplicación de ISO 9001 para el desarrollo, implementación y mantenimiento de software".

El objetivo de la ISO 9001 es construir un sistema de calidad el cual contenga la estructura de la organización, responsabilidades, procedimientos, procesos y recursos para implementar una dirección de calidad. Mientras que el de la ISO 9000-3 es proveer las especificaciones de cómo aplicar la ISO 9001 al desarrollo del software, implementación y mantenimiento. Se incluyen algunos temas que no se encuentran en las normas ISO 9000 genéricas, tales como Administración de la Configuración o Planeación de Proyectos. Sería poco probable lograr resultados de calidad en un proyecto de desarrollo software de tamaño mediano, sin haber tomado las provisiones necesarias para el control de configuración. Esto implica que para ciertos productos o servicios, la especificación de requerimientos contenida en las normas genéricas ISO 9000 no es suficiente para asegurar la calidad, y esto justifica la necesidad de otras normas o guías más específicas.

La norma ISO 9000-3 es requerida por todas las compañías desarrolladoras de software:

• Para poder incursionar en la competencia del mercado europeo.
• Como un medio para cubrir las expectativas de los clientes.
• Para obtener beneficios de calidad y ventajas competitivas en el mercado.
• Como parte de la estrategia del mercado.
• Estrategia para reducir los costos de producción

Dentro de los beneficios que se obtienen de la certificación ISO 9000-3, se encuentran:

• Mejor documentación de los sistemas.
• Cambio cultural positivo.
• Incremento en la eficiencia y productividad.
• Mayor percepción de calidad.
• Se amplía la satisfacción del cliente.
• Se reducen las auditorías de calidad de los clientes.
• Agiliza el tiempo de desarrollo de un sistema.

La dirección de la empresa debe definir y documentar su política y sus objetivos con respecto a la calidad. :la empresa debe asegurarse que esta política es conocida, entendida e implementada en todos los niveles de la organización.

Las responsabilidades, autoridades y relaciones entre todo personal, cuyo trabajo afecte la calidad del producto, deben ser definidas: particularmente de aquéllos quienes necesitan de la libertad organizacional y autoridad.

La empresa debe establecer y mantener un sistema de calidad documentado (un manual interior como guía de operaciones del sistema de calidad) como medio de asegurar que los productos cumplen con los requerimientos especificados, y debe incluir:

• La preparación de procedimientos e instructivos del sistema de calidad de acuerdo con los requerimientos de esta especificación
• La aplicación efectiva de los procedimientos y de las instrucciones documentadas del sistema de calidad.

La empresa debe establecer y mantener procedimientos para la revisión de los contratos y para la coordinación de estas actividades. Cada contrato debe ser revisado por la empresa para asegurar que:

• Los requisitos están adecuadamente definidos y documentados
• Sean definidos los requerimientos diferentes de aquellos mencionados en la propuesta.
• La empresa tenga la capacidad de cumplir con todos los requerimientos contractuales.

La empresa debe establecer y mantener procedimientos para controlar todos los documentos y datos que se relacionen con esta norma. Incluyendo documentos externos como especificaciones de clientes, etc. Este control debe asegurar que:

• Los documentos y su emisión correcta están disponibles en todo lugar pertinente.
• Los documentos obsoletos sean removidos rápidamente de los lugares de uso o emisión.

La empresa debe establecer y mantener procedimientos para la verificación, almacén y mantenimiento de productos provistos por el comprador para ser incorporados al producto final. Cualquiera de estos productos que se pierda, dañe, o que sea no apto para usarse, debe ser reportado al proveedor.

Donde sea apropiado la empresa debe establecer y mantener procedimientos para identificar el producto desde la etapa de diseño hasta la entrega e instalación, pasando por todas las etapas de producción. Cuando la trazabilidad del producto sea un requisito especificado, los productos individuales o los, lotes deben tener una identificación única. Este identificador debe ser registrado.

La empresa debe asegurar que los productos adquiridos no se utilicen o procesen hasta que sean inspeccionados o verificados que cumplen con los requerimientos específicos. Las verificaciones deben estar de acuerdo con el plan de calidad y los procedimientos documentados.

Cuando los productos son enviados a producción por situaciones de urgencia sin ser antes inspeccionados, éstos deben identificarse y registrarse para que en caso de no conformidad sean rápidamente reconocidos y reemplazados.

La empresa debe establecer o mantener registros que contengan el criterio de aceptación del producto.

La empresa debe controlar, calibrar y mantener el equipo de inspección, medición y pruebas (sin importar si el equipo es propiedad de la empresa, rentado o si es provisto por el comprador) para verificar la conformidad del producto con los requerimientos especificados. El equipo debe ser usado de una manera que asegure que la incertidumbre de medición sea conocida y que esté dentro de la capacidad de medición requerida. La empresa debe:

• Precisar las mediciones a efectuar, con la exactitud requerida y además, seleccionar el equipo adecuado de inspección y pruebas.
• Identificar, calibrar y ajustar a intervalos definidos todo el equipo de inspección, medición y pruebas y los elementos que afectan la calidad del producto. Esta calibración se efectúa contra equipo certificado que tenga una relación con patrones internacionales. Cuando no exista esa norma o patrón, la base utilizada para la calibración deberá ser documentada.
• Establecer, documentar y mantener los procedimientos de calibración que incluyan detalles del equipo en cuanto tipo, identificación, número, ubicación, frecuencia de verificación, criterios de aceptación y las acciones a tomar cuando los resultados no sean satisfactorios.
• Asegurarse de que el equipo de inspección, medición y pruebas registra la exactitud, el error y la precisión requerida.
• Identificar al equipo de inspección, medición y pruebas con un indicador que muestre el status de la calibración del equipo.
• Mantener registros de calibración del equipo de inspección, medición y pruebas.
• Auditar y documentar la validez de los resultados de las inspecciones y pruebas cuando los equipos de medición, inspección y pruebas sean encontrados sin calibración.
• Asegurar los equipos de inspección, medición y pruebas para evitar ajustes que invaliden la calibración. Esto incluye a los programas computacionales de pruebas.

El estado de inspección y pruebas del producto debe ser identificado mediante marcas, etiquetas autorizadas, sellos, rótulos, registros de inspección, programas computacionales de pruebas , localizaciones físicas, etc.

Estos elementos deben indicar la conformidad o no-conformidad del producto con respeto a las pruebas e inspecciones efectuadas. La identificación del estado y pruebas debe ser mantenida en el proceso de producción e instalación del producto para asegurar que sólo los que hayan pasado las pruebas e inspecciones requeridas sean entregados al cliente.

La empresa debe mantener y controlar los procedimientos que aseguren que los productos que no cumplan los requerimientos especificados, no sean usados o instalados inadvertidamente. Se deben controlar las actividades de identificación, documentación, evaluación, segregación (cuando sea practico) y desecho de productos no-conformes, sin olvidar la notificación a las áreas y funciones interesados.

La empresa debe establecer, documentar y mantener procedimientos para lo siguiente:

• Investigar la causa de no conformidad y las acciones correctivas necesarias para prevenir la recurrencia.
• Analizar todos los procesos, operaciones de trabajo, registros de calidad, reportes de servicios y reclamaciones de clientes para determinar y eliminar causas potenciales de productos no conformes.
• Iniciar sesiones de prevención para manejar problemas a un nivel acorde al riesgo encontrado.
• Aplicar controles para asegurar que las acciones correctivas sean tomadas y que sean efectivas.
• Implantar y registrar los cambios en los procedimientos que sean resultado de acciones correctivas.

La empresa debe establecer, documentar los procedimientos para el manejo, almacén, empaque y embargue de los productos.

La empresa debe proveer métodos y medios para prevenir daños y deteriorización durante el manejo, almacén, empaque y embargue de los productos.

La empresa debe proveer áreas de almacén seguras para prevenir daños de los productos que estén pendientes de usarse o de entregarse. Se deben definir métodos apropiados para automatizar la recepción y la entrega de y hacia esas áreas. Se debe revisar periódicamente las condiciones del producto.

La empresa debe controlar el empaque, la conservación y el marcado hasta el grado necesario para asegurar que el producto cumpla con los requisitos especificados. Se debe identificar conservar y mantener todo el producto desde el recibo hasta que la responsabilidad de la empresa termine.

La empresa debe establecer y mantener procedimientos para identificar, recolectar, indexar, llenar, archivar y desechar los registros de calidad Todos los registros deben ser legibles e identificables con el producto del que se trate. El tiempo que deberán mantenerse esos registros debe ser definidos y registrados.

La empresa debe llevar un sistema de auditorias internas de calidad, planeado y documentado, para verificar que las actividades de calidad cumplan con lo planeado y que determine la efectividad del sistema de calidad. Las auditorias deben programarse de acuerdo con la importancia de la actividad. La auditoria y el seguimiento deben llevarse a cabo de acuerdo a los procedimientos documentados. El resultado de las auditorias debe ser documentado y mostrado al personal que tenga responsabilidad en el área auditada. El personal administrador responsable del área debe tomar acciones correctivas sobre las deficiencias encontradas por la auditoría.

La empresa debe establecer y mantener procedimientos para identificar las necesidades de capacitación y proveer entrenamiento a todo el personal que realice tareas especificas debe ser calificado con base en su educación, entrenamiento y/o experiencia, Se deben mantener registros apropiados de capacitación.

Cuando sea apropiado, la empresa debe establecer los procedimientos para identificar técnicas estadísticas adecuadas, requeridas para verificar la capacidad de proceso y características del producto

ALBA CASTRO, Mauricio Fernando. Calidad en la producción de software. En : Calidad de Software. Primer Congreso Nacional de Estudiantes de Ingeniería de Sistemas. Universidad de Manizales. Mayo 1992.

BOOCH, Grady. Object Oriented Design with Applications. Prentice Hall. 1991.

COAD, Peter y YOURDON, Edward. Object Oriented Analysis. Prentice Hall. 1990.

DUNN, Robert. Software Quality. Prentice Hall. 1990. Cap 1.

CROSBY, Philip. Quality is Free. McGraw Hill. 1979.

HUMPHREY, Watts S. A discipline for software engineering. 1.999.

MCGARRY, John. Practical Software Measurement. Addisson Wesley. 2001.

MEYER, Bertrand. Object Oriented Software Constructions. Englewood Cliffs, Prentice Hall. 1998.

PRESSMAN, Roger S. Ingeniería del Software, Un enfoque practico. Tercera edición. McGraw Hill Cap 12.

VILLALOBOS, Jorge. La programación orientada por objetos : El paradigma del futuro. En Revista : Sistemas N. 48. 1991.

Ingeniero de Sistemas

UNIVERSIDAD DE MANIZALES