4.3.- Control o Garantía de Calidad de los Sistemas de Información.

Revisiones Técnicas Formales.

    Una revisión técnica formal (RTF) es una actividad de garantía de calidad de los sistemas de información. Los objetivos de la RTF son :
  1. Describir errores en la función, la lógica o la implementación de cualquier representación de los sistemas de información.
  2. Verificar que los sistemas bajo revisión alcancen sus requisitos.
  3. Garantizar que los sistemas han sido representados de acuerdo con ciertos estándares predefinidos.
  4. Conseguir un sistema desarrollado en forma uniforme.
  5. Hacer que los proyectos sean más manejables.
    También sirve como campo de entrenamiento para que el personal más joven puedan observar los diferentes enfoques al análisis, diseño e implementación de los sistemas. EL RTF Sirve para promover la seguridad y continuidad, ya que varias personas se familiarizarán con partes del sistema de información, que de otro modo, no hubieran visto. Es una clase de revisión que incluye recorridos, inspecciones, torneo de revisiones y otras tareas de revisión técnica de los sistemas. Cada RTF se lleva a cabo mediante una reunión y sólo tendrá éxito si es bien planificada, controlada y atendida. La reunión de revisión Independientemente del formato que se elija para la RTF, cualquier reunión de revisión debe apegarse a las siguientes restricciones:     De acuerdo a las delimitaciones anteriores, resulta obvio cada RTF se centra en una parte específica (y pequeña) del sistema total. Por ejemplo, en lugar de revisar un diseño completo, se hacen inspecciones para cada módulo o grupos de módulos. Al limitarse el centro de atención del RTF la posibilidad de descubrir errores es mayor. El centro de atención del RTF es un producto- un componente del sistema. El individuo que realiza el producto -productor- informa al jefe de proyecto que el producto ha sido terminado y necesita revisarse. El jefe de proyecto contacta al jefe de revisiones, que es el que evalúa la disponibilidad del producto, genera copias del material del producto y las distribuye a dos o tres revisores para que se preparen por adelantado. Estos revisores estarán una o dos horas revisando el producto, tomando notas y familiarizándose con el trabajo. De forma concurrente el jefe de revisión revisa el producto y establece una agenda para la reunión de revisión. La reunión de revisión es llevada a cabo por el productor, jefe de revisión y los revisores. Uno de los revisores toma el papel de registrador, es decir, la persona que registra en forma escrita todos los sucesos importantes que se generen.

    La RTF empieza con una explicación de la agenda y una pequeña introducción por parte del productor. Entonces el productor procede con el recorrido de inspección del producto (explica el material), mientras que los revisores exponen sus pegas basándose en su preparación previa.

    Cuando se descubren los errores o problemas el registrador los va anotando. Al final de la revisión, los participantes de la revisión deben decidir si:

    Una vez tomada la decisión los participantes deben firmar para indicar que participaron en la revisión y que están de acuerdo con las conclusiones. Registro e informe de la revisión

    Durante la RTF uno de los revisores registra todas las pegas que vayan surgiendo. Al final las resúme y genera una lista de sucesos de revisión . Además prepara un informe sumario de revisión. Dicho informe responde a tres cuestiones:

  • ¿ ¿Qué fué revisado ?
  • ¿ ¿Quién lo revisó ?
  • ¿ ¿Qué se descubrió y cuáles son las conclusiones ?
    •  A continuación se muestra un formato de un informe sumario de revisión :

        Informe sumario de revisión técnica Identificación de la revisión;Proyecto: Número de revisión; Fecha; Lugar; Identificación del producto; Material revisado; Productor; Breve descripción; Material Revisado: (cada elemento por separado) 1.- 2.- . . n.- Equipo de revisión: Nombre; Firma Aprobación del proyecto; Aceptado: como está ( ) con modificaciones menores ( ) No aceptado: revisión principal ( ); revisión secundaria ( ); Revisión no terminada: (explicar) Material adicional adjunto: Lista de sucesos ( ), Materiales de producción anotados ( ), Otros (especifíque).

    La lista de sucesos sirve para dos propósitos :

    1. Para identificar áreas problemáticas dentro del producto.
    2. Servir como lista de puntos de acción que guíe al productor para realizar las correcciones. Formato de Lista de sucesos Número de revisión: Fecha de revisión: Jefe de revisión: Lista de sucesos: 1.- 2.- 3.- . . . n.- Directríces para la revisión: Se deben establecer directríces para conducir las RTF, distribuyéndolas entre los revisores para que sean seguidas, ya que una revisión incontrolada puede ser peor que no hacer ninguna revisión.
    Estas son algunas de las directríces para las RTF :
    1. Revisar el producto no el productor.- Una RTF involucra gente y egos, debe de llevar a los integrantes a un sentimiento agradable de estar cumpliendo con su deber. Se deben señalar los errores correctamente; el tono de la reunión debe ser distendido y constructivo; no debe intentarse dificultar o batallar. El jefe de revisión debe moderar la reunión para garantizar que se mantiene un tono y una actitud adecuados.
    2. Fijar una agenda y mantenerla.- No realizar la reunión a la deriva. La RTF debe seguir un plan de trabajo concreto. El jefe debe mantener el plan de la reunión y cortar a la gente cuando empiece a divagar.
    3. Limitar el debate y las impugnaciones. Cuando un supervisor proporcione una pega, puede no ser unánime, en lugar de discutirla registrar el hecho y la discusión se lleve a cabo en otro momento.
    4. Enunciar áreas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto. Una reunión no es una sesión de resolución de problemas, se debe dejar eso al productor por si solo o con la ayuda de otra persona.
    5. Tomar notas escritas. Es conveniente que el registrador anote en una pizarra, de forma que las declaraciones puedan ser comprobadas por los demás revisores.
    6. Limitar el número de participantes e insistir en la preparación anticipada. No es conveniente un número grande de revisores, ya que puede no haber la debida comunicación y además deben de prepararse por anticipado (el jefe de la revisión debe pedir comentarios escritos para saber si realmente se revisó el material).
    7. Llevar a cabo un entrenamiento adecuado de los revisores. Todos los participantes deben tener un entrenamiento formal, principalmente en aspectos relacionados con el proceso, así como las consideraciones psicológicas humanas que atañen a la revisión.
    8. Repasar las revisiones anteriores. Las revisiones de información pueden ser beneficiosas para descubrir problemas en el propio proceso de revisión. El primer producto que se haya revisado puede establecer las directivas de revisión. METRICAS DE LA CALIDAD DEL SOFTWARE Es difícil obtener medidas precisas acerca de la calidad del software. A continuación se tratará un conjunto de métricas del software que se pueden aplicar para garantizar cuantitativamente la calidad del software. En todos los casos estas métricas representan medidas indirectas, es decir, nunca se mide realmente la calidad del software, sino algunas de sus manifestaciones. Indices de calidad de los sistemas de información.
        Se ha desarrollado una serie de indicadores de calidad del software basados en las características de diseño medíbles para un programa de computadora, utilizando información obtenida a partir del diseño arquitectónico y de datos para obtener un índice de calidad de la estructura del diseño (ICED), que va de 0 a 1. Para calcular el ICED se tienen que averiguar los siguientes valores: Una vez que se cuenta con esos valores se calculan los siguientes valores intermedios :     Teniendo esos valores el ICED se calcula de la siguiente manera: ICED= i Di. Donde i varía de 1-6, pi es el peso relativo de la importancia de cada uno de los valores intermedios y i =1 (si todos los Di tienen el mismo peso, entonces pi = 0,167).

        Se puede calcular el ICED para anteriores diseños y compararlo con un diseño en desarrollo y si es considerablemente menor es que requerirá un posterior trabajo de diseño y de revisión. Igualmente si se requieren hacer cambios considerables se puede calcular el efecto de esos cambios en el ICED. También se sugiere un índice de madurez de los sistemas, que proporciona una indicación de la estabilidad de un producto (basada en los cambios que se producen en cada versión del producto). Se determina la siguiente información:

        El índice de madurez de los sistemas se calcula de la siguiente manera: IMS = A medida que el IMS se aproxíma a 1, el producto comienza a estabilizarse.El IMS también se puede utilizar como métrica para la planificación de actividades del mantenimiento. Prueba de corrección Un programa se contempla como una secuencia de instrucciones que implementan una función determinada. En varios puntos de la secuencia el diseñador del programa puede determinar (a partir de la especificación) el valor correcto de las variables, el estado conveniente de la información de control y otras relaciones internas. Por lo tanto las sentencias selecionadas S1, S2, ..., Sn del programa, por lo tanto se puede asegurar que determinadas condiciones C1, C2, ..., C3 son ciertas sin excepción. Para probar la corrección del programa, se tienen que demostrar que las sentencias del programa que se encuentran entre las sentencias seleccionadas Si y Si+1 hacen que la condición confirmada Ci se transforme en Ci+1.

        Avanzando incrementalmente, se puede mostrar que la aplicación del programa a la entrada producirá las condiciones de salida confirmadas al final del programa. Un enfoque análogo se utiliza para demostrar la correspondencia entre la especificación formal y el programa.
     

    Garantía de calidad estadística.

        La garantía de calidad estadística refleja una tendencia creciente en toda la industria de establecer más cuantitativa la calidad. La garantía de calidad estadística implica los siguientes pasos :

    1. Se agrupa y se clasifica la información sobre los defectos existentes.
    2. Se intenta encontrar la causa subyacente de cada defecto.
    3. Mediante el principio de Pareto (el 80% de los defectos se pueden encontrar en el 20% de todas las posibles causas), se aísla el 20 % (los pocos pero vitales).
    4. Una vez que se han identificado los defectos vitales, se actúa para corregir los problemas que han producido los defectos.
        Es importante tener en cuenta que la acción correctora se centra básicamente en los defectos vitales. A medida que se corrigen las causas vitales, aparecen nuevas candidatas en lo alto de la pila. Proceso limpio. La verificación formal de programas (pruebas de corrección) y la SQA estadística se han combinado en una técnica que mejora la calidad del producto de software.

        Denominado proceso limpio o ingeniería del software limpia, se puede resumir de la siguiente manera : Con el proceso limpio, se puede llevar un control de calidad estadístico, igual que con el desarrollo de hardware limpio, la mayor prioridad del proceso es la prevención de los defectos, más que la eliminación de defectos. Esta primera prioridad se consigue mediante la verificación matemática (pruebas de corrección) en lugar de la depuración de programas que se prepara para la prueba del sistema. La siguiente prioridad es proporcionar una certificación estadística válida de la calidad de los sistemas. La medida de la calidad viene dada por el tiempo medio hasta que se produce el fallo.
     

    Fiabilidad del software.

        No hay duda que la fiabilidad de un programa de computadora es un elemento importante de su calidad general. Si un programa falla frecuentemente en su funcionamiento, no importa si el resto de los factores de calidad son aceptables.

    La fiabilidad del software, a diferencia de otros factores de calidad, puede ser medida o estimada mediante datos históricos o de desarrollo. La fiabilidad del software se define en términos estadísticos como la probabilidad de operación libre de fallos de un programa de computadora es un entorno determinado y durante un tiempo específico Siempre que se habla de fiabilidad, surge una pregunta fundamental ¿ qué se entiende por el término fallo ? En el contexto de cualquier disquisición sobre calidad y fiabilidad del software, el fallo es cualquier falla de concordancia con los requisitos del software. Incluso en esta definición existen grados. Los fallos pueden ser simplemente desconcertantes o ser catastróficos. Puede que un fallo sea corregido en segundos mientras que otro lleve semanas o incluso meses. Para complicar más las cosas, la corrección de un fallo puede llevar a la introducción de otros errores que, finalmente, lleven a más fallos. Medidas de fiabilidad y de disponibilidad. Los primeros trabajos sobre fiabilidad intentaron explotar las matemáticas de la teoría de fiabilidad del hardware a la predicción de la fiabilidad del software. La mayoría de los modelos de fiabilidad relativos al hardware van más orientados a los fallos debidos al desajuste que a los fallos debidos a defectos del diseño. En el hardware, son más probables los fallos debidos al desgaste físico que los fallos relativos al diseño. Desgraciadamente para el software lo que ocurre es lo contrario. De hecho todos los fallos del software, se producen por problemas de diseño o de implementación; el desajuste no entra en este panorama.

    Considerando un sistema basado en computadora, una sencilla medida de la fiabilidad es el tiempo medio entre fallos (TMEF), donde : TMEF = TMDF + TMDR TMDF Tiempo Medio De Fallo TMDR Tiempo Medio De Reparación Además de una medida de fiabilidad debemos obtener una medida de la disponibilidad. La disponibilidad del software es la probabilidad de que un programa funcione de acuerdo con los requisitos en un momento dado, y se define como : La medida de fiabilidad TMEF es igualmente sensible al TMDR que al TMDF. La medida de disponibilidad es algo más sensible al TMDR, una medida indirecta de la facilidad de mantenimiento del software.
     

    Modelos de fiabilidad del software.

        Para modelizar la fiabilidad del software, se deben considerar primero los principales factores que le afecten : Introducción de fallos, eliminación de fallos y entorno. La introducción de fallos depende principalmente de las características del código desarrollado y de las características del proceso de desarrollo. La característica del código más significativa es el tamaño. Entre las características del proceso del desarrollo se encuentran las tecnologías y las herramientas de ingeniería del software usadas, y el nivel de experiencia del personal. Se puede desarrollar código para añadir posibilidades o para eliminar fallos. La eliminación de fallos depende del tiempo, del perfil operativo. Como algunos los anteriores factores son de naturaleza probabilística y se dan en el tiempo, los modelos de fiabilidad del software generalmente se formúlan en términos de procesos aleatorios.

    Los modelos de fiabilidad del software entran en dos grandes categorías :

    1. Modelos que predicen la fiabilidad como una función cronológica del tiempo (calendario).
    2. Modelos que predicen la fiabilidad como una función del tiempo de procesamiento transcurrido (tiempo de ejecución de CPU).
    Se han propuesto modelos estocásticos mucho más sofisticados para la fiabilidad del software:     Como parte de la seguridad del software, se puede dirigir un proceso de análisis y modelización. Inicialmente, se identifican los riesgos y se clasifican por su importancia y su grado de riesgo. Cuando se han identificado estos riesgos del sistema, se utilizan técnicas de análisis para asignar su gravedad y su probabilidad de ocurrencia. Para que se efectivo, se tiene que analizar el software en el contexto del sistema completo. El análisis del árbol de fallos construye un modelo gráfico de las combinaciones secuenciales y concurrentes de los sucesos que pueden conducir a un suceso o estado del sistema peligroso. Mediante un árbol de fallos bien desarrollado, es posible observar las consecuencias de una secuencia de fallos interrelacionados que ocurren en diferentes componentes del sistema. La lógica de tiempo real (LTR) construye un modelo del sistema mediante la especificación de los sucesos y las acciones correspondientes. El modelo suceso-acción se puede analizar mediante operaciones lógicas para probar las valoraciones de seguridad de los componentes del sistema y su temporización. Se pueden usar los modelos de redes de Petri para determinar los riesgos más peligrosos. Cuando se han identificado y analizado los riesgos, se pueden especificar requisitos del software relacionados con la seguridad. La espeficación puede contener una lista de sucesos no deseables y la respuestas del sistema deseadas a dichos sucesos.
     
    Un enfoque para la garantía de calidad del software.

        Todas las organizaciones de desarrollo de software tienen algún mecanismo de garantía de calidad. En el nivel inferior de la escala, la calidad es responsabilidad únicamente del individuo que deba crear, revisar y probar el software a cualquier nivel de conformismo. En el nivel superior de la escala, existe un grupo de SQA que carga con la responsabilidad de establecer estándares y procedimientos para conseguir la calidad del software y asegurar que se sigue cada uno de ellos. Antes de institucionalizar procedimientos formales de garantía de calidad, una organización de desarrollo de software debe adoptar procedimientos, métodos y herramientas de ingeniería del software. Esta metodología, combinada con un paradigma efectivo para el desarrollo de software, puede hacer mucho por mejorar la calidad de todo el software para el desarrollo de software, además de mejorar la calidad de todo el software desarrollado por la organización. El primer paso a dar como parte de un decidido esfuerzo por institucionalizar los procedimientos de garantía de calidad del software es una auditoría SQA/GCS. El estado actual de la garantía de calidad del software y de la gestión de configuraciones del software se evalúa examinando los siguientes puntos :

    Ventajas:
    1. El software tendrá menos defectos latentes, resultando un menor esfuerzo y un menor tiempo durante la prueba y el mantenimiento.
    2. Se dará una mayor fiabilidad y, por lo tanto, una mayor satisfacción del cliente.
    3. Se podrán reducir los costos de mantenimiento.
    4. El coste del ciclo de vida total del software disminuirá.
    Desventajas:
    1. Es difícil de institucionalizar en organizaciones pequeñas, en las que no están disponibles los recursos necesarios para llevar a cabo esas actividades.
    2. Representa un cambio cultural ,y el cambio nunca es fácil.
    3. Requiere un gasto que, de otro modo, nunca se hubiera destinado explícitamente a ingeniería del software o a la garantía de calidad.
        En un nivel fundamental, la SQA es efectiva en coste si : C3 > C1 + C2 donde C3 es el coste de los errores que aparecen sin un programa de SQA, C1 es el coste del propio programa de SQA y C2 es el coste de los errores que no se encuentran con las actividades de SQA. 1

     
     
    Página anterior Página siguiente