4.2.- Control del Procesamiento de la Información.
El control del procesamiento garantiza que los datos se están transformando en información, en forma exacta y confiable. La recopilación de datos representa el subsistema vital de las operaciones generales de un sistema de información.
Los controles de procesamiento se dividen en controles de entrada, de programación, de banco de datos, de salidas, de equipo.
Los controles de entrada son los diseños de formas, las verificaciones, los totales de control, entre otros…
- Diseño de Forma : Cuando se requiere algún documento fuente para recopilar datos el formato del documento puede diseñarse de manera que obligue a hacer los asientos en forma más legíble, mediante el uso de cuadros individuales para cada letra o cifra que deba registrarse.
- Verificación : Los documentos fuentes formulados por un solo empleado los puede verificar otro empleado, con el fin de verificar la exactitud. Al efectuarse la operación de conversión, por ejemplo grabación en cinta o grabación en disco, el documento puede ser verificado por el segundo operador. El operador verificador realiza las mismas operaciones que el original; pero su operación es comparada por la lógica de la máquina con los asientos hechos anteriormente, marcando toda discrepancia, por medio de mensajes que se originan desde la máquina. La verificación es una operación de duplicación, de manera que dobla el costo de la conversión de datos. Para reducir este costo, podría hacerse lo siguiente:
- Verificar únicamente ciertos campos, por ejemplo, las cantidades de dinero y los números de cuenta, pasando por alto los domicilios, nombres, etc.
- Marcar por anticipado los campos que se repiten constantemente y registrar sólo los campos variables.
- Usar la programación para hacer la comprobación.
- Totales de Control : Con el fin de reducir al mínimo la pérdida de datos cuando se transportan de un lugar a otro lo mismo que para comprobar los resultados de diferentes procesos, se preparan totales de control para cada lote de datos. Por ejemplo, un lote de documentos fuente, que pueden ser las tarjetas de tiempo de una división de la planta, se remite al empleado de control de sistema de información. Este empleado prepara una cinta con los números de trabajadores (control fragmentario) y con el total de horas trabajadas. Estos totales de control se registran en una hoja de control. Los documentos fuente se transfieren luego a un departamento donde se captura la información. Esta información junto con las correspondientes a otros lotes se convierten en cintas magnéticas de nóminas. Al terminar cada etapa de procesamiento, los totales de control introducidos a esa etapa se pueden comparar con los totales de control generados por la computadora. Esto garantiza que se cuenta con todos los datos, hasta la terminación del procesamiento y producción de resultados. Estableciendo totales de control en el momento de introducirlos a proceso, los controles de procesamiento restantes, ya sean manuales o programados pueden establecerse sobre la misma base.
- Otros controles : Durante el diseño del sistema de recopilación de datos de entrada, el analista también debe considerar, el empleo de dígitos de comprobación para los códigos más importantes, como son el número de cuenta del cliente, el número de producto, el número de empleado, etc. La rotulación de archivos de datos es otro punto de control muy importante. Los rótulos contienen informes tales como el nombre de archivo, la fecha de creación, la fecha de actualización, el período de expiración, etc.
Los diseños de formas se utilizan para obligar a hacer los asientos en una forma más legíble. La vericación se hace con el fin de verificar la exactitud. Los totales de control se utilizan para comprobar los resultados de diferente proceso.
Otro tipo de control, es utilizar dígitos de comprobación para códigos importantes. Los controles de programación permiten que algunas computadoras ayuden a detectar errores durante el procesamiento. Por ejemplo, la comprobación de límites, pruebas aritméticas, la identificación de datos válidos y el registro de errores.
- Comprobación de límites o de racionalidad.- Este control sirve para identificar aquellos datos que tengan un valor superior o inferior a una cantidad predeterminada. Estos límites estándar superior e inferior se establecen mediante una investigación que realiza el analista. Esta técnica de control detecta sólo aquellos elementos de información que quedan fuera de los límites. He aquí algunos ejemplos de su aplicación:
- Ningún cliente con código A podrá comprar a crédito por más de $ 1,000.
- Si las tarifas por hora, mínima y máxima, que se pagan a los empleados son $ 2.50 y $ 10.50, cualquier tarifa que se salga de esos límites estará equivocada.
- Prueba aritmética.- Es posible diseñar varias rutinas de cálculo para validar el resultado de otro cálculo, o el valor de ciertos campos. Un método de prueba aritmética es el llamado de cifras cruzadas, que significa sumar o restar dos o más campos e igualar a cero el resultado comparado con el resultado original. Este método de control es aplicable cuando se lleva por cada cuenta la suma de los cargos, la suma de los abonos y el saldo de adelantos. Por ejemplo, en la cuenta de efectivo, si la suma de los cargos es de $ 5000 y la suma de los abonos es de $ 4,000, el saldo de efectivo deberá ser de $ 1,000.
- Identificación.- Es posible diseñar varias técnicas de identificación para asegurarse de que los datos que se procesan son válidos. Esto puede hacerse comparando los campos del archivo de transacciones con los archivos maestros, o con tablas de constantes, almacenadas ya sea en el programa mismo o en un dispositivo periférico. Por ejemplo, cada número de cliente asentado en el archivo de despacho de pedidos se compara con el archivo maestro de clientes. Si no se localiza un registro maestro del cliente, se rechaza el registro del pedido.
- Comprobación de secuencias.- A menudo, los archivos se disponen en secuencia ascendente o descendente, por ejemplo, por número de empleado, por número de cuenta, etc. Las instrucciones del programa compara el campo de secuencia del registro o transacciones que le anteceden. Mediante esta técnica, se detectará cualquier registro fuera de secuencia, evitándose que el archivo se procese incorrectamente. Las razones normales para que se produzca un error de secuencia son :
- Uso de un archivo incorrecto.
- Que no se haya efectuado la clasificación correcta.
- Descomposturas de las máquinas.
- Intercalación indebida.
- Registro de errores.- Una técnica fundamental de control que se usa durante el procesamiento consiste en llevar un registro de errores donde aparecen todos los errores y excepciones observados en el curso del procesamiento. Al irse identificando los errores, se registran en un archivo especial, permitiendo que el procesamiento continúe sin interrupción. Al terminarse esa etapa se consulta el registro de errores, ya sea que lo haga el operador o por medio de la computadora, decidiéndose si se continuará o no con el procesamiento. Luego, el registro de errores se envía ya sea al departamento o grupo que prepara los elementos de entrada originales o a un grupo de control designado especialmente dentro del sistema de información, donde se corrigen los asientos, se concilian y se comenten de nuevo a procesamiento.
- Otros controles de programación.- La computadora se puede programar de manera que interprete, anote y valíde los rótulos de cada archivo de datos procesados. Los códigos que utilizan dígitos de verificación se pueden generar y validar con los controles de programación. Por último, los totales de control se pueden mantener y tomar para referencia en cada etapa del procesamiento empleando la lógica de programación.
Los controles de banco de datos son establecer procedimientos que permitan proteger los datos contra pérdida y destrucción. En caso de que llegara a ocurrir algún accidente se debe contar con los procedimientos necesarios para reconstruir los archivos y programas. Se debe almacenar la información en un lugar construído a prueba de incendios, donde haya control sobre los factores ambientales, debe ser un lugar seguro, contruir o rentar un lugar fuera del centro de cómputo, entregar información sólo a personas autorizadas, y rotular archivos y programas.
Los bancos de datos y los programas son la materia prima y la savia vital del sistema de información. Siendo estos factores tan fundamentales para la operación efectiva de todo el sistema, es preciso establecer y observar procedimientos para protegerlos contra pérdidas y destrucción. Si llega a haber pérdidas o destrucción deberán seguirse procedimientos planeados previamente para reconstruir los archivos y los programas. Mediante el empleo de controles de programación, el analista de sistemas puede garantizar, hasta cierto punto, que esos archivos y programas no se dañarán durante el procesamiento normal; pero, en combinación con los administradores respectivos del sistema de información y del banco de datos, debe ejercer un control adicional sobre los aspectos físico y de operación relacionados con el procedimiento y almacenamiento de archivos de datos y programas. Por lo común, los archivos y los programas permanecen almacenados en un depósito, en espera de ser procesados. Es aquí donde deben tomarse las medidas necesarias para asegurarse de que no se dañarán ni se usarán indebidamente. Las precauciones son las siguientes:
- El lugar de almacenamiento debe estar construido a prueba de incendios para evitar grandes pérdidas ocasionadas por este tipo de siniestros.
- Los factores ambientales, como la temperatura, la humedad y el aire, se deben controlar adecuadamente.
- El lugar de almacenamiento debe ser seguro, los archivos y otros dispositivos vitales se deben almacenar en un lugar seguro. A menos que así se haga, se podrán copiar y devolver sin que nadie se entere. Los archivos magnéticos también se pueden dañar o distorsionar debido a la presencia de imánes y otros dispositivos. Los imánes pueden alterar los datos grabados en cinta magnética, circunstancia que impone la necesidad de procurarse en un buen lugar de almacenamiento.
- Es preciso utilizar anillos protectores. Estos anillos de material plástico o de metal, protegen los archivos contra la destrucción accidental. Por ejemplo, si es necesario grabar sobre un archivo de cinta, el operador le pone un anillo protector antes de montarlo en el dispositivo de manejo de cintas. Si se intenta grabar en una cinta que no tenga esa protección sobrevienen circunstancias que impiden se efectúe la grabación.
- La empresa puede construir o rentar lugares de almacenamiento fuera del lugar de operación, con el fin de dar protección adicional a los archivos y programas importantes. El personal de operación del centro de computación, lo mismo que el encargado de la biblioteca siguen ciertos procedimientos de control para asegurarse de que los archivos y programas se manejen con propiedad, y que, si alguno de ellos llega a destruirse o a perderse accidentalmente, se habrá especificado un método para reconstruirlo. Dichos procedimientos son los siguientes:
-
- Todos los archivos y programas deben estar claramente rotulados y clasificados para su fácil identificación.
- El acceso a las áreas de almacenamiento sólo se debe permitir al personal autorizado.
- Todos los archivos, programas y otros documentos importantes deben ser proporcionados exclusivamente a las personas autorizadas para recibirlos. Es decir, debe implantarse un procedimiento sistemático para la entrega y recepción de los documentos almacenados en la biblioteca.
A pesar de los procedimientos implantados, a veces se destruyen los archivos, o bien, los datos se vuelven ilegíbles, debido a diversas causas. Para solucionar este problema, el analista de sistemas planea una protección, es decir, un método para reconstruir los registros perdidos. En el caso de archivos almacenados en cinta magnética el método que más se usa consiste en conservar los antíguos archivos maestros y de transacciones cuando se prepara uno nuevo actualizado. A este método se le denomina del abuelo-padre-hijo, puesto que en todo momento se dispone de tres versiones del archivo. En el caso de los dispositivos de almacenamiento de acceso directo, el método que permite la reconstrucción de archivos consiste en vaciar periódicamente el contenido en otro dispositivo, que es casi siempre una cinta magnética. La frecuencia de esta operación dependerá de la proporción de actividad y de la volatilidad del archivo. Por ejemplo, un archivo maestro probablemente se protegerá con más frecuencia que un archivo histórico típico.
En el caso de los archivos maestros clásicos de acceso directo, generalmente se específica una protección diaria o un archivo de protección. Con la protección diaria se simplifica la reconstrucción, puesto que el archivo protegido el día de ayer se puede procesar con las transacciones de hoy, obteniéndose uno actualizado. Desde luego, se sigue el mismo procedimiento aunque el archivo no sea protegido a diario. Mientras mayor sea la frecuencia de la protección, más alto será el costo. Igualmente, a medida que aumenta el número de dispositivos de acceso directo, la protección diaria de todos ellos se torna menos deseable en virtud del tiempo de UCP que se requiere para efectuarlo.
Hay que tener presente que los métodos de reconstrucción aplicables a los archivos de datos también se pueden aplicar a la reconstrucción de planes de programación. Por ejemplo, cada vez que se introduce un cambio en el programa debe trasladarse el dispositivo de protección, por ejemplo, la cinta magnética, para el caso de que se necesite la reconstrucción. En las diversas organizaciones se siguen diferentes métodos para implantar los archivos de protección. La mayoría de las instalaciones visitadas emplea métodos un poco diferentes para establecer la protección diaria y para caso de desastre. No parece haber un sistema “estándar”.
Controles de Salida.
Debemos tener una inspección inicial para detectar los errores más obvios, debemos asegurarnos de que sólo reciban los resultados las personas autorizadas, los totales de control de salida deben coincidir con los totales de control de entrada.
Los procedimientos de control de salida se establecen como una comprobación de salida, se establecen como una comprobación final de la precisión e integridad de la información procesada. Estos procedimientos son los siguientes:
- Una inspección inicial, para detectar los errores más obvios.
- La comunicación de los resultados se debe controlar, para asegurarse de que sólo los reciben las personas autorizadas.
- Los totales de control de salida se deben conciliar con los totales de control de entrada, para asegurarse de que no se han perdido ni agregado datos durante el procesamiento o la comunicación. Por ejemplo, el número de registros que se envían a procesamiento debe ser igual al número de registros procesados; o deben coincidir los totales fraccionarios o los totales financieros, como son las percepciones netas.
- Todas las formas fundamentales (cheques de pago, registros de acciones, etc.) se deben numerar previamente y controlar.
- Pese a todas las precauciones, se cuelan algunos errores. Por supuesto, el principal punto de control para detectarlos lo constituye el usuario, de manera que el analista de sistemas debe establecer procedimientos para crear un canal de comunicación entre el usuario y el grupo de control, con vistas al reporte sistemático de errores e incongruencias. El sistemático de errores e incongruencias. El diseño de este sistema debe establecer un circuito de retroalimentación por medio del cual el usuario pueda informar de todos los errores al grupo de control, y éste a su vez emprenda la acción necesaria para corregir las inexactitudes e inconsistencias observadas.
Hay otros controles de salida, como son la comprobación manual sistemática, el muestreo estadístico manual sistemático, el muestreo estadístico, el recuento físico de inventarios y el análisis de informes. Pueden crearse muchos métodos para controlar los resultados, pero el nivel de control debe ir de acuerdo con la sensibilidad de dichos resultados. Por ejemplo, los cheques de pago de sueldos deben controlarse estrictamente, mientras que los informes estadísticos departamentales requieren poco control.
Control de Equipo.
Los controles de equipo se establecen con el fin de detectar las fallas eléctricas y mecánicas que ocurren en el equipo de cómputo y dispositivos periféricos. Se deben de implementar revisiones y procedimientos de mantenimiento preventivo. Estos tienen como objetivo hacer ajustes y reparaciones antes de que se produzca una falla, disminuyendo así, las probabilidades de error. Los probadores integrales automáticos garantizan el buen funcionamiento ( verificación de paridad, de validez ).
Controles de Seguridad.
Los controles de seguridad son indispensables en todo sistema de información. Le corresponde a la dirección general estar al tanto de y cuidar que se hagan cumplir las medidas de seguridad. Estas medidas deben tenerse ya que si bien es cierto, implican un alto costo no estando comparado con lo que pasaría si nos lo tuvieramos.
Además, la administración tiene la obligación legal de establecer las medidas de seguridad. Por ejemplo, los grupos de seguridad, que son sistemas grandes y complejos, responsables del acceso a los usuarios, de la integridad del programa y de la recuperación de datos en caso de un siniestro. También el acceso por parte de los usuarios debe hacerse en base a un código especial, que generalmente representa las clases de acceso ( listas ) y el área de responsabilidad.
Finalmente el acceso controlado de los visitantes casuales propios y extraños. Propensos al fraude, el sabotaje y descontento. Esto puede prevenirse colocando vigilantes, asignando días para las visitas, uso de gafetes, etc.
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 :
- Describir errores en la función, la lógica o la implementación de cualquier representación de los sistemas de información.
- Verificar que los sistemas bajo revisión alcancen sus requisitos.
- Garantizar que los sistemas han sido representados de acuerdo con ciertos estándares predefinidos.
- Conseguir un sistema desarrollado en forma uniforme.
- 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:
- Deben convocarse a la revisión entre tres y cinco personas.
- Se debe preparar por adelantado, pero sin que requiera más de dos horas de trabajo a cada personas.
- La duración de la reunión de revisión debe ser menor de dos horas.
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:
- Aceptan el producto sin posteriores modificaciones.
- Rechazan el producto debido a los serios problemas encontrados (una vez corregidos se debe realizar otra revisión).
- Aceptan el producto provisionalmente (se han encontrado errores menores que deben ser corregidos, pero no se necesita una posterior revisión).
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 :
- Para identificar áreas problemáticas dentro del producto.
- 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 :
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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 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 :
- Se agrupa y se clasifica la información sobre los defectos existentes.
- Se intenta encontrar la causa subyacente de cada defecto.
- 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).
- 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 :
- Modelos que predicen la fiabilidad como una función cronológica del tiempo (calendario).
- 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:
- Validez predictiva. La posibilidad de que el modelo prediga el comportamiento de fallo futuro basándose en los datos obtenidos de las fases de prueba y de operación.
- Capacidad. La posibilidad de que el modelo genere datos que puedan ser fácilmente aplicados a los esfuerzos de desarrollo de software industriales.
- Calidad de suposiciones. La plausibilidad de las suposiciones en las que se basan los fundamentos matemáticos del modelo cuando se llega a los límites de esas suposiciones.
- Aplicabilidad. El grado en que se puede aplicar un modelo de fiabilidad en diferentes terrenos y tipos de aplicación del software.
- Simplicidad. El grado en que el conjunto de datos que soportan el modelo es directo; el grado en que el enfoque y las matemáticas son intuitivos; el grado en que se puede automatizar el enfoque general.
- Seguridad del software. La seguridad del software es una actividad de garantía de calidad del software que se centra en la identificación y evaluación de los riesgos potenciales que pueden producir un impacto negativo en el software y hacer que falle el sistema completo.
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 :
- Principios.
- Organización.
- Interfases funcionales Beneficios SQA
Ventajas:
- El software tendrá menos defectos latentes, resultando un menor esfuerzo y un menor tiempo durante la prueba y el mantenimiento.
- Se dará una mayor fiabilidad y, por lo tanto, una mayor satisfacción del cliente.
- Se podrán reducir los costos de mantenimiento.
- El coste del ciclo de vida total del software disminuirá.
Desventajas:
- 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.
- Representa un cambio cultural ,y el cambio nunca es fácil.
- 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
¿COMO TRABAJAN LAS SERIES? ISO
La ISO 9000 da al usuario las guías de consulta para la selección y el uso de ISO 9001, 9002, 9003 y 9004. La ISO 9001, 9002, y 9003 son modelos de sistema de calidad para la garantía de calidad externa. Estos tres modelos son realmente subconjuntos sucesivos de uno y otro. La ISO 9001 es la más comprensiva –abarca el diseño, fabricación, instalación, y sistemas de mantenimiento.
La ISO 9002 cubre la producción e instalación, y la ISO 9003 cubre solamente el examen y prueba finales del producto. Estos tres modelos fueron desarrollados para usarse en situaciones contractuales tales como aquellas entre un cliente y un surtidor. La ISO 9004 proporciona las guías de consulta para el uso interno en un productor que desarrolla su propio sistema de calidad al conocer las necesidades de los negocios y quiere tomar ventajas de las oportunidades.
| SELECCIÓN Y USO DE ESTANDARES |
——————————————- |
ISO 9000 |
| USO INTERNO DENTRO DEL PRODUCTOR |
MANEJO DE CALIDAD Y ELEMENTOS DE SISTEMAS DE CALIDAD |
ISO 9004 |
| USO EXTERNO PARA GARANTIZAR LA CALIDAD |
TRES MODELOS PARA ASEGURAR LA CALIDAD |
ISO 9001, 9002 Y 9003 |
La decisión de cual modelo implementar depende del alcance de su operación. Por ejemplo, si usted diseña su propio producto o servicio, usted debe considerar la ISO 9001. Si usted fabrica solamente (trabajando en el diseño de alguien) usted puede considerar la ISO 9002. Finalmente, si usted ni diseña ni fabrica, usted puede considerar ISO 9003.
¿QUIÉN LAS ESTA USANDO?
Las corporaciones alrededor del globo han construido y continúan construyendo sus sistemas de calidad alrededor de estos estándares. Las compañías grandes y pequeñas con negocios internacionales perciben la ISO 9000 series como una ruta a los mercados abiertos y a la competitividad mejorada. Usted no tiene que ser una corporación multinacional o tener negocios extranjeros a beneficiar de poner estos estándares en ejecución en su compañía.