Directríces para la revisiones técnicas formales

Estas son algunas de las directrices 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:

• S1 =Número total de módulos definidos en la arquitectura del programa.
• S2 = Número de módulos cuya correcta función depende de la fuente de los datos de entrada.
• S3 = Número de módulos cuya correcta función depende del procesamiento previo.
• S4 = Número de elementos de una base de datos.
• S5 = Número total de elemento de una base de datos únicos.
• S6 = Números de segmentos de base de datos (registros diferentes u objetos individuales.
• S7 = Número de módulos con una sola entrada y una sola salida.

Una vez que se cuenta con esos valores se calculan los siguientes valores intermedios:

• Estructura del programa:D1, Si el diseño se desarrollo usando un método característico ( Diseño orientado al flujo de datos o a objetos) D1=1, en caso contrario D1=0.
• Independencia de módulos: D2= 1-(S2/S1).
• Módulos no dependientes del procesamiento previo: D3= 1-(S3/S1).
• Tamaño de la base de datos: D4= 1-(S5/S4).
• Compartimentalización de la base de datos: D5= 1-(S6/S4).
• Características de entrada/salida del módulo: D6= 1-(S7/S1).

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:

• Mt = Número de módulos en la versión actual.
• Fm =Número de módulos en la versión actual que han sido modificados.
• Fa = Número de módulos en la versión actual que han sido añadidos.
• Fe = Número de módulos de la versión anterior que se han eliminados en la versión actual.

El índice de madurez de los sistemas se calcula de la siguiente manera: IMS = A medida que el IMS se aproxima 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.

Fuente: Apunte Administración de servicios de cómputo del Instituto tecnológico de la Paz