onceptos generales y principios de calidad de software

Programa de Ingeniera de Sistemas Calidad de Software CAPSULA 2

Universidad del Cauca 1

CONCEPTOS GENERALES Y PRINCIPIOS DE CALIDAD DE SOFTWARE

1. CONCEPTOS GENERALES Control de calidad. Involucra la serie de inspecciones, revisiones y pruebas empleadas a lo largo del proceso de software para garantizar que cada producto (tanto intermedio como final) satisfaga los requisitos que se le han asignado. El control de calidad incluye un ciclo de realimentacin con el proceso que cre el

producto. La combinacin de medicin y realimentacin permite afinar el proceso cuando los productos fracasan en cuanto a satisfacer sus especificaciones. Un concepto clave del control de calidad es que todos los productos tienen especificaciones mensurables (medibles) con las cuales se puede comparar la salida de cada proceso. El ciclo de realimentacin es esencial para minimizar los defectos producidos. Garanta de la calidad. Consiste en un conjunto de funciones de auditora e informacin que evalan cun

efectivas y completas son las actividades de control de calidad. La meta del aseguramiento de la calidad es brindarle al gestor los datos necesarios para que est informado acerca de la calidad del producto, y verificar si el producto (o el proceso) est satisfaciendo sus metas. Si los datos suministrados por el aseguramiento

de calidad identifican problemas, es responsabilidad del gestor abordarlos y aplicar los recursos necesarios para resolverlos.

Costo de la calidad. Incluye todos los costos que genera la bsqueda de la calidad o que demanda el desarrollo de las actividades relacionadas con ella. Los costos de la calidad se dividen en costos asociados con prevencin, evaluacin y fallas.

Los costos de prevencin incluyen planificacin de la calidad, revisiones tcnicas formales, equipo de pruebas y entrenamiento.

Los costos de evaluacin incluyen actividades para comprender mejor la condicin del producto por medio de cada proceso (o sub-proceso), como ejemplo de esos costos tenemos a las inspecciones de proceso, calibracin y mantenimiento de equipo y pruebas.

Los costos de fallas son aquellos que se extinguiran si no aparecieran defectos (que son los que ve el cliente). Estos costos se subdividen en costos de fallas internas y externas. Se incurre en costos de

fallas internas cuando se detecta un error en el producto antes de entregarlo al cliente. Los costos de fallas internas incluyen re-elaboracin, reparacin y anlisis de la falla. Los costos de fallas externas se asocian con defectos detectados despus que el producto ha sido enviado al cliente. Ejemplos de estos costos son la resolucin de las quejas, devolucin y reemplazo del producto, soporte de ayuda en lnea y trabajo de garanta.

Est comprobado que el costo relativo de encontrar y reparar un error aumenta sustancialmente de la

siguiente manera: Si lo encontramos en actividades de Nos costar Diseo de 3 a 6 veces ms que si lo encontramos en Requisitos. Codificacin aproximadamente 10 veces ms. Pruebas (unitarias/integracin) de 15 a 40 veces ms.

Pruebas de sistema de 30 a 70 veces ms. Operacin / Produccin (entregado) de 40 a incluso 1000 veces ms. La primera gran falla de calidad en software: La falta de concordancia con los requisitos funcionales. Los requisitos son la base de las medidas de calidad.

La segunda gran falla de calidad en software: El no seguir criterios o estndares especificados para el seguimiento del proceso de desarrollo y del producto que se va obteniendo. La tercera gran falla de calidad en software: El olvidarse de los requisitos no funcionales o no dejarlos explcitos en la documentacin.

Y no lo olviden: TOMA MENOS TIEMPO HACER UNA COSA BIEN QUE EXPLICAR POR QU LA HICISTE MAL.



2. PRINCIPIOS DE CALIDAD DE SOFTWARE

2.1. GARANTIA (O ASEGURAMIENTO) DE CALIDAD DE SOFTWARE (GCS / SQA). La administracin de la calidad, incluye tres actividades principales: Aseguramiento de la calidad. Establecimiento de un marco de trabajo con procedimientos y

estndares corporativos que conduzcan a la obtencin de software de alta calidad. Planificacin de la calidad. Seleccin de procedimientos y estndares adecuados a partir de ese marco

de trabajo y adaptacin de stos para un proyecto de software especfico. Control de la calidad. Definicin y aplicacin de los procesos que aseguren que los procedimientos y

estndares son seguidos por el equipo de desarrollo. SQA engloba: Mtodos y herramientas de anlisis, diseo, codificacin y prueba. Revisiones tcnicas formales que se aplican durante cada paso de la ingeniera del software. Pruebas de software secuenciadas en mltiples pasos y con mtodos especficos de diseo de casos.

Control de la documentacin del software y de los cambios realizados. Procedimientos que aseguren un ajuste a los estndares de desarrollo de software. Mecanismos de medida y de informacin.

Mtricas para medir la calidad del software. Todo este proceso se realiza de forma interna. La propia organizacin puede tener un grupo de SQA que se encargue de la realizacin de todas las tareas necesarias. Es posible tener un grupo de consultores externos dedicados a SQA pero, a menos que la organizacin tenga una mediana actividad de desarrollo, los costes

econmicos de esta opcin pueden ser elevados. Actividades de aseguramiento de la calidad (SQA). El punto de partida de un grupo encargado de SQA es definir un marco de trabajo para lograr la calidad del software, lo que implica definir o seleccionar estndares aplicables al proceso de desarrollo o a los productos de software. Importancia de los estndares:

Ofrecen un conjunto de las mejores prcticas, evitando repetir errores anteriores y capturando el

conocimiento de valor para la organizacin. Ofrecen un marco de trabajo alrededor del que se implementa el proceso de SQA. Ayudan a la continuidad del trabajo de unos ingenieros a otros. Es fundamental:

Evitar la percepcin de los estndares como elementos burocrticos e irrelevantes. Involucrar a los ingenieros de software en el desarrollo de los estndares del producto; inclusin del por qu de

las decisiones en el documento de estndares (Comprensin de los motivos de los estndares as como compromiso con su desarrollo y utilizacin).

Revisin y modificaciones regulares para reflejar cambios en las tecnologas y las circunstancias.

Utilizacin de herramientas para simplificar la aplicacin de los estndares. Evitar la aplicacin rigurosa y fundamentalista de los estndares del proceso.

El administrador puede adaptar los estndares del proceso segn las circunstancias del proyecto. Colaboracin entre administrador de proyecto y administrador de SQA para definir la forma de aplicar los

estndares en cada proyecto.

Importancia de los documentos estandarizados. Documentos: nica forma tangible de representar el software y el proceso del software. Documentos estandarizados: apariencia, estructura y calidad consistentes; ms fciles de leer y

comprender. La garanta de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos

diferentes: Los ingenieros de software que realizan trabajo tcnico.

Un grupo de SQA que tiene la responsabilidad de la Planificacin de garanta de calidad, supervisin, mantenimiento de registros, anlisis e informes.



stas son las actividades que realizan (o facilitan) un grupo independiente de SQA:

A. Establecimiento de un plan de SQA para un proyecto. El plan se desarrolla durante la planificacin del proyecto y es revisado por todas las partes interesadas. Las actividades de garanta de calidad realizadas por el equipo de ingeniera del software y el grupo SQA son gobernadas por el plan. El plan identifica:

Evaluaciones a realizar. Auditoras y revisiones a realizar. Estndares que se pueden aplicar al proyecto. Procedimientos para informacin y seguimiento de errores. Documentos producidos por el grupo SQA.

Realimentacin de informacin proporcionada al equipo de proyecto del software. B. Participacin en el desarrollo de la descripcin del proceso de software del proyecto. El equipo de ingeniera del software selecciona un proceso para el trabajo que se va a realizar. El grupo de SQA revisa la descripcin del proceso para ajustarse a la poltica de la empresa, los estndares internos del software, los

estndares impuestos externamente, y a otras partes del plan de proyecto del software.

C. Revisin de las actividades de ingeniera del software para verificar su ajuste al proceso de software definido. El grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y verifica que se han hecho las correcciones. D. Auditora de los productos de software para verificar el ajuste con los definidos como parte del

proceso del software. El grupo de SQA revisa los productos seleccionados; verifica que se han hecho las correcciones, e informa peridicamente de los resultados de su trabajo al gestor del proyecto. E. Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripcin del proceso, en los estndares aplicables o en los productos tcnicos.

F. Registrar lo que no se ajuste a los requisitos e informar a sus superiores. Los elementos que no se ajustan a los requisitos estn bajo seguimiento hasta que se resuelven.

Adems de estas actividades, el grupo de SQA coordina el control y la gestin de cambios y ayuda a recopilar y a analizar las mtricas del software.

2.2. ENFOQUES FORMALES A LA SQA Todo lo que se ha comentado hasta ahora de SQA se concreta en la prctica en un conjunto de actividades que se deben realizar durante el desarrollo de sistemas. Debido a esto, previamente se seal que son actividades de control, no de auditora.

Revisiones Tcnicas Formales. Una revisin tcnica formal (RTF) es una actividad de garanta de calidad del software llevada a cabo por los ingenieros del software (y otros). Los objetivos de la RTF son: (1) Descubrir errores en la funcin, la lgica o la implementacin de cualquier representacin del software; (2) Verificar que el software bajo revisin alcanza sus requisitos;

(3) Garantizar que el software ha sido representado de acuerdo con ciertos estndares predefinidos;

(4) Conseguir un software desarrollado de forma uniforme (5) Hacer que los proyectos sean ms manejables. La RTF es realmente una clase de revisin que incluye recorridos, inspecciones, revisiones cclicas y otro pequeo grupo de evaluaciones tcnicas del software. Cada RTF se lleva a cabo mediante una reunin y slo tendr xito si es bien planificada, controlada y atendida. Las directrices bsicas de una RTF son:

2.1. Sobre la reunin de revisin. Independientemente del formato que se elija para la RTF, cualquier reunin de revisin debe acogerse a las siguientes restricciones: Deben convocarse para la revisin (normalmente) entre tres y cinco personas; Se debe preparar por adelantado, pero sin que requiera ms de dos horas de trabajo a cada persona; La duracin de la reunin de revisin debe ser menor de dos horas.



Con las anteriores limitaciones, debe resultar obvio que cada RTF se centra en una parte especfica (y

pequea) del software total. Por ejemplo, en lugar de intentar revisar un diseo completo, se hacen

inspecciones para cada mdulo (componente) o pequeo grupo de mdulos. Al limitar el centro de atencin de la RTF, la probabilidad de descubrir errores es mayor. Al final de la revisin, todos los participantes en la RTF deben decidir si:

(1) Aceptan el producto sin posteriores modificaciones; (2) Rechazan el producto debido a los serios errores encontrados (una vez corregidos, ha de hacerse otra revisin) (3) Aceptan el producto provisionalmente (se han encontrado errores menores que deben ser corregidos, pero sin

necesidad de otra revisin).

Una vez tomada la decisin, todos los participantes terminan firmando, indicando as que han participado en la revisin y que estn de acuerdo con las conclusiones del equipo de revisin. 2.2. Registro e informe de la revisin. Durante la RTF, uno de los revisores (el registrador) procede a registrar todas las inconformidades que vayan surgiendo. Al final de la reunin de revisin, resume todas las inconformidades y genera una lista de sucesos de revisin. Adems, prepara un informe sumario de la

revisin tcnica formal. El informe sumario de revisin responde a tres preguntas: 1. Qu fue revisado? 2. Quin lo revis? 3. Qu se descubri y cules son las conclusiones? El informe sumario de revisin es una pgina simple (con posibles suplementos). Se adjunta al registro histrico del proyecto y puede ser enviada al jefe del proyecto y a otras partes interesadas.

La lista de sucesos de revisin sirve para dos propsitos: (1) Identificar reas problemticas dentro del producto

(2) Servir como lista de comprobacin de puntos de accin que gue al productor para hacer las correcciones. 2.3. Directrices para la revisin. Se deben establecer de antemano directrices para conducir las revisiones tcnicas formales, distribuyndolas despus entre los revisores, para ser consensuadas y, finalmente,

seguidas. A menudo, una revisin incontrolada puede ser peor que no hacer ningn tipo de revisin. A continuacin se muestra un conjunto mnimo de directrices para las revisiones tcnicas formales:

1. Revisar el producto, no al productor. Conducida adecuadamente, la RTF debe llevar a todos los participantes a un sentimiento agradable de estar cumpliendo su deber. Si se lleva a cabo incorrectamente, la RTF puede tomar el aura de tribunal de la inquisicin. 2. Fijar una agenda y mantenerla. Un mal de las reuniones de todo tipo es la deriva. La RTF debe seguir un plan de trabajo concreto. El jefe de revisin es el que carga con la responsabilidad de mantener el plan de la reunin y no debe tener miedo de cortar a la gente cuando se empiece a divagar. 3. Limitar el debate y las impugnaciones. Cuando un revisor ponga de manifiesto una pega, podr no haber unanimidad sobre su impacto. En lugar de perder el tiempo debatiendo la cuestin, debe registrarse el hecho y dejar que la cuestin se lleve a cabo en otro momento. 4. Enunciar reas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto. Una revisin no es una sesin de resolucin de problemas. 5. Tomar notas escritas. A veces es buena idea que el registrador tome las notas en una pizarra, de forma que las declaraciones o la asignacin de prioridades pueda ser comprobada por el resto de los revisores, a medida que se va registrando la informacin. 6. Limitar el nmero de participantes e insistir en la preparacin anticipada. Mantener nmero de participantes en

el mnimo. Adems, los miembros del equipo de revisin deben prepararse por anticipado. 7. Desarrollar una lista de comprobacin para cada producto que haya de ser revisado. Una lista de comprobaciones ayuda al jefe de revisin a estructurar la reunin de RTF y ayuda a cada revisor a centrarse en los asuntos importantes. Se deben desarrollar listas de comprobaciones para los documentos de anlisis, de diseo, de codificacin e incluso de prueba. 8. Disponer recursos y una agenda para las RTF. Para que las revisiones sean efectivas, se deben planificar como una tarea del proceso de ingeniera del software. Adems se debe trazar un plan de actuacin para las modificaciones inevitables que aparecen como resultado de una RTF. 9. Llevar a cabo un buen entrenamiento de todos los revisores. Por razones de efectividad, todos los participantes en la revisin deben recibir algn entrenamiento formal.



10. Repasar las revisiones anteriores. Las sesiones de informacin pueden ser beneficiosas para descubrir problemas en el propio proceso de revisin. El primer producto que se haya revisado puede establecer las propias directivas de revisin. Resumiendo, una RTF tiene los siguientes principios: Se revisa UN producto: especificacin, mdulo, listado, etc. Poca gente, preparacin y duracin breves. Participantes: jefe de revisin, revisores (ingenieros, programadores, etc.) y productor. Decisin final: (1) Aceptacin. (2) Rechazo. (3) Aceptacin condicionada a pequeas modificaciones.

Una RTF tiene los siguientes Objetivos: Descubrir errores. Verificar el cumplimiento de los requisitos. Garantizar el cumplimiento de los estndares. Conseguir un desarrollo uniforme del software. Obtener proyectos que hagan ms sencillos los trabajos tcnicos (anlisis que permitan buenos diseos, diseos que

permitan implementaciones sencillas, estrategias de pruebas que faciliten stas,...)

Ejemplo de un Informe Sumario: Identificacin de la revisin Proyecto: Controlador del CM en tiempo real Nmero revisin: D-004 Fecha: 11/07/2008 Lugar: Edif. 4, Desp. 3 Hora: 10:00AM Identificacin del producto Material revisado: Diseo detallado. Mdulos de control de movimiento Productor: Juan Prez Breve descripcin: tres mdulos para el control de movimiento en los ejes x, y,z Material revisado:

1. Descripciones del diseo procedimental: mdulos MOVIMX, MOVIMY, MOVIMZ 2. Codificacin de los mdulos

Equipo de revisin Nombre Firma

1. M. Prez Prez _______________ 2. J. Garca Conde _______________ 3. E. Snchez _______________

Aprobacin del producto Aceptado: como est ( ) con modificaciones menores ( x) No aceptado: revisin principal ( ) revisin secundaria ( ) Revisin no terminada (explicacin a continuacin) Material adicional adjuntado Lista de sucesos (X) Materiales de produccin anotados (X) Otros (especificar)

Ejemplo de Lista de Sucesos: Nmero revisin: D-004 Fecha: 11/07/95 Jefe de revisin: M. Prez Prez Lista de sucesos: Los prlogos de los mdulos MOVIMX, MOVIMZ no son consistentes con los estndares de diseo. Se debe establecer explcitamente el propsito del mdulo y se debe especificar la declaracin de los elementos de datos. El contador de bucle para la interpolacin de los ejes X, Y, Z se incrementa una vez ms de lo necesario para el control de paso del motor. El equipo de revisin recomienda otra comprobacin de las especificaciones de paso del motor y la correccin (como sea preciso) del contador de bucle. Error de tipo en la referencia a la posicin actual en X, X.POSICIN, en los mdulos MOVIMX y MOVIMZ. Ampliar una sentencia de seudocdigo. La sentencia converger a posicin de control adecuada como en MOVIMX contenida en los mdulos MOVIMY y MOVIMZ debe ampliarse para controles especficos de movimiento en Y y Z. Se recomienda una modificacin del algoritmo de comparacin de posicin para mejorar el rendimiento en tiempo de ejecucin. Se tienen reservas sobre las modificaciones y analizar el posible impacto antes de implementar los cambios.



2.3. GARANTIA DE CALIDAD ESTADISTICA

Segmentos de la comunidad de ingenieros de software vienen sosteniendo que debe implementare una serie

de controles ms rigurosos, de tipo matemtico y estadstico. 2.3.1. Proceso limpio de creacin de software. Se centra en la consecucin del objetivo de nmero de defectos nulo. La idea terica central es conseguir la verificacin matemtica de la correccin de elementos de un sistema de informacin. Sin embargo, por el momento no se ha conseguido llevar a la prctica esta

idea para sistemas medianamente complejos. En segundo lugar, se debe proporcionar una certificacin de calidad estadstica. Para ilustrar este proceso, supongamos que una organizacin de desarrollo de software recoge informacin sobre defectos durante un ao (esto puede constituir por s mismo un proyecto de control). Aunque se descubran cientos de errores diferentes, todos ellos pueden encuadrarse dentro de una o varias causas.

Los errores detectados debern ser clasificados en tres categoras: Graves, Moderados, Leves. Con estas dos clasificaciones (causa e importancia) se podrn establecer conclusiones estadsticas, que permitirn tomar medidas de correccin. Esta tcnica permite efectuar una eliminacin sistemtica de las causas de los

defectos empezando por los ms serios y mejorando la utilizacin de los recursos. Para el software, la garanta de calidad estadstica implica los siguientes pasos: 1. Se agrupa y se clasifica la informacin sobre los defectos del software.

2. Se intenta encontrar la causa subyacente de cada defecto (por ejemplo, no concordancia con la especificacin, error de diseo, incumplimiento de los estndares, pobre comunicacin con el cliente).

3. Mediante el principio de Pareto (el 80 por 100 de los defectos se pueden encontrar en el 20 por 100 de todas las posibles causas), se asla el 20 por 100 (los pocos vitales).

4. Una vez identificados los defectos vitales, se acta para corregir los problemas que han producido los defectos. Este concepto relativamente sencillo representa un paso importante hacia la creacin de un proceso de ingeniera del software adaptativo en el cual se realizan cambios para mejorar aquellos elementos del proceso que introducen errores.

Para ilustrar el proceso, supongamos que una organizacin de desarrollo de software recoge informacin

sobre defectos durante un perodo de un ao. Algunos de los defectos se descubren mientras se desarrolla el software. Otros se encuentran despus de que el software se haya distribuido al usuario final. Aunque se descubren cientos de errores diferentes, todos se pueden encontrar en una (o ms) de las siguientes causas: EIE: Especificacin incompleta o errnea. MCC: Mala interpretacin de la comunicacin del cliente. DDE: Desviacin deliberada de la especificacin. IEP: Incumplimiento de los estndares de programacin. ERD: Error en la representacin de los datos. IMI: Interfaz de mdulo inconsistente. ELD: Error en la lgica de diseo. PIE: Prueba incompleta o errnea. DII: Documentacin imprecisa o incompleta. TLP: Error en la traduccin del diseo al leng. de program. IHM: Interfaz hombre-mquina ambigua o inconsistente. VAR: Varios.

Para aplicar la SQA estadstica se construye una tabla como la siguiente:

TOTAL GRAVE MODERADO LEVE

EIE 205 22% 34 27% 68 18% 103 24%

MCC 156 17% 12 9% 68 18% 76 17%

DDE 48 5% 1 1% 24 6% 23 5%

IEP 25 3% 0 0% 15 4% 10 2%

ERD 130 14% 26 20% 68 18% 36 8%

IMI 58 6% 9 7% 18 5% 31 7%

ELD 45 5% 14 11% 12 3% 19 4%

PIE 95 10% 12 9% 35 9% 48 11%

DII 36 4% 2 2% 20 5% 14 3%

TLP 60 6% 15 12% 19 5% 26 6%

IHM 28 3% 3 2% 17 4% 8 2%

VAR 56 6% 0 0% 15 4% 41 9%

942 100% 128 100% 379 100% 435 100%

13,59% 40,23% 46,18%

Tabla 1. Ejemplo de recoleccin de defectos y su distribucin clasificados por causa e importancia.



La tabla 1 indica que EIE, MCC y ERD son las causas vitales que contabilizan el 53 por 100 de todos los

errores. Sin embargo, debe observarse que si slo se consideraran errores serios, se seleccionaran las

siguientes causas vitales: EIE, ERD, TLP y ELD. Una vez determinadas las causas vitales, la organizacin de desarrollo de software puede comenzar la accin correctiva. Es importante destacar que la accin correctiva se centra principalmente en las causas vitales. Cuando stas son corregidas, nuevas candidatas saltan al principio de la lista. La clave es: Utilizar el tiempo para centrarse en cosas que realmente interesan, pero primero hay que asegurarse de que entendemos qu es lo que realmente interesa. 2.3.2. Medidas de fiabilidad. La fiabilidad del software se define en trminos estadsticos como la probabilidad de operacin libre de fallos de un programa en un entorno determinado y durante un tiempo especfico. Una sencilla medida de fiabilidad es el tiempo medio entre fallos (MTBF, Mean Time Between Failures) o TMEF. El cual relaciona las siguientes variables:

TMEF = TMDF + TMDR MTBF = MTTF + MTTR TMDF: Tiempo Medio de Fallo (Mean Time To Failure MTTF). Puede describirse como el nmero de horas transcurridas hasta el momento en que un componente, mdulo o incluso el sistema entero falle. Es una medida usada frecuentemente en anlisis de confiabilidad y mantenibilidad. TMDR: Tiempo Medio de Reparacin (Mean Time To Repair MTTR). Tiempo medio gastado en una reparacin contado a partir de la comunicacin del envo, contando desplazamiento del personal y duracin de reparacin de la unidad averiada.

Muchos investigadores argumentan que esta medida es ms eficiente que la medida que se usa generalmente para evaluar la cantidad de errores, que es el nmero de errores por cada mil lneas de cdigo. Un ejemplo y ms conceptos. La Tabla 2 contiene un simple juego de datos usados para ilustrar la manera

como se calculan algunas habilidades.

HORAS Tiempo transcurrido

Comienzo Final operacin parada

0,0 708,2 708,2

708,2 711,7 3,5

711,7 754,1 42,4

754,1 754,7 0,6

754,7 1867,5 1112,8

1867,5 1887,4 19,9

1887,4 2336,8 449,4

2336,8 2348,9 12,1

2348,9 4447,2 2098,3

4447,2 4452,0 4,8

4452,0 4559,6 107,6

4559,6 4561,1 1,5

4561,1 5443,9 882,8

5443,9 5450,1 6,2

5450,1 5629,4 179,3

5629,4 5658,1 28,7

5658,1 7108,7 1450,6

7108,7 7116,5 7,8

7116,5 7375,2 258,7

7375,2 7384,9 9,7

7384,9 7952,3 567,4

7952,3 7967,5 15,2

7967,5 8315,3 347,8

8315,3 8317,8 2,5

TOTALES 8205,3 112,5

MTTF 683,8

MTTR 9,4

Tabla 2. Datos en bruto procedentes de las bitcoras de operacin



Los eventos son colocados en categoras de tiempos en servicios y tiempos de paradas, para el sistema.

Dado que en los datos faltan detalles especficos de las fallas, los intervalos de funcionamiento son

frecuentemente considerados como datos genricos de tiempos para fallar. Del mismo modo, los detalles especficos de mantenimiento son frecuentemente considerados como tiempos genricos de reparacin. Al aadir mas detalles a los reportes se incrementa su utilidad. La Disponibilidad es una medida de qu tan frecuente el sistema est bien y listo para operar. Esta es

frecuentemente expresada como (tiempo en servicio) / (tiempo en servicio + tiempo en parada) Frecuentemente se utilizan tres ecuaciones de disponibilidad, las cuales se explican a continuacin. Disponibilidad Inherente, tal como es vista por el personal de Mantenimiento, (excluye las paradas por Mantenimientos Preventivos, demoras en suministros, y demoras administrativas), y es definida como:

Ai = MTBF/(MTBF + MTTR)

Disponibilidad Lograda, tal como es vista por el Departamento de Mantenimiento, (incluye tanto el Mantenimiento Correctivo como el Preventivo, pero no incluye demoras en suministros y demoras administrativas), y es definida como:

Aa = MTBM/(MTBM + MAMT)

Donde MTBM es el Tiempo medio Entre acciones Correctivas y Preventivas, y MAMT es el Tiempo Medio en que Mantenimiento estuvo Activo. Disponibilidad Operacional, tal como es vista por el usuario, y es definida como:

Ao = MTBM/(MTBM + MDT)

Donde MDT es el tiempo medio de parada.

Un ejemplo de 98% de disponibilidad para un proceso continuo, dice que se espera un tiempo de servicio de 0.98*8760 = 8584.8 hr/ao y de parada de 0.02*8760 = 175.2 hr/ao, dado que:

disponibilidad + (no disponibilidad) = 1

Ahora, usando el listado de datos de la Tabla 2, la disponibilidad dicotomizada es 98.64% basada en un tiempo de servicio = 8205.3 horas y un tiempo de parada = 112.5 horas. Por supuesto que la visin dicotomizada de la disponibilidad es simplista y entrega cifras de disponibilidad

pobres para este caso. No todos los equipos en un proceso suministran resultados binarios de solo servicio o solo parada (algunas veces estn parcialmente en servicio o parcialmente en parada). La Confiabilidad R (del ingls Reliability) se relaciona con la reduccin en la frecuencia de las fallas en un intervalo de tiempo, y es una medida de la probabilidad para una operacin libre de fallas, durante un intervalo de tiempo dado; as, es una medida del xito para una operacin libre de fallas. Se expresa as:

R(t) = exp(-t/MTBF) = exp(-t)

donde es la rata constante de falla y MTBF es el Tiempo Medio Entre Fallas. Los datos de la Tabla 1 muestran que el tiempo medio entre acciones de mantenimiento es de 683.8 horas. Calcule la confiabilidad del sistema usando las distribuciones exponenciales descritas, y un tiempo de corrida de un ao. El sistema tiene una confiabilidad de exp(-8760/693.2) = 0.00032%.

El valor de confiabilidad es la probabilidad de cumplir un ao de corrida sin fallas. En pocas palabras, el sistema es altamente no-confiable (para un ao de operacin), y las acciones de mantenimiento tienen una alta demanda, dado que para el sistema se espera que tenga 8760/693.2 = 12.6 acciones de mantenimiento por ao! Y, Cmo puede lograrse una alta disponibilidad con sistemas que requieren muchas acciones de mantenimiento? Las acciones de mantenimiento deben realizarse muy rpidamente para minimizar paradas!

--------------------------------------------------------------------------------------------------------- FIN DEL DOCUMENTO

onceptos generales y principios de calidad de software

Documents