INGENIERÍA DE SOFTWARE II GRUPO: Capt. Rudel HuancasCapt. Rudel Huancas Pablo GuanoluisaPablo Guanoluisa Mishell ParedesMishell Paredes FIABILIDAD

DEFINICIÓN DE FIABILIDAD Capacidad del software de mantener las prestaciones requeridas del sistema, durante un tiempo establecido y bajo un conjunto de condiciones definidas.

SUB CARACTERÍSTICAS:  Madurez. - Se debe verificar las fallas del sistema y si muchas de estas han sido eliminadas durante el tiempo de pruebas o uso del sistema.  Recuperabilidad.- Verificar si el software puede reasumir el funcionamiento y restaurar datos perdidos después de un fallo ocasional.  Tolerancia a fallos.- Evalúa si la aplicación desarrollada es capaz de manejar errores.  Conformidad de la fiabilidad: La capacidad del software de cumplir a los estándares o normas relacionadas a la fiabilidad.

SUB CARACTERÍSTICAS: La calidad del software se evalúa teniendo en cuenta la etapa del desarrollo, se deben fijar las metas de la calidad tanto para el software final como para desarrollos incompletos y tener en cuenta que es imposible que las metas y criterios sean iguales para un software pequeño y un gran software empresarial.

MÉTRICAS MÉTRICAEXPLICACIÓN Probabilidad de fallos en la petición La probabilidad de que el sistema falle cuando se solicite una petición de servicio. PODFOD de 0,001 significa que una de cada peticiones de servicio conduce a un fallo. Tasa de ocurrencia de fallos La frecuencia de ocurrencia con la que es probable que ocurra un comportamiento inesperado. Un ROCF de 2/100 significa que es probable que ocurran dos fallos a cada 100 unidades de tiempo de funcionamiento. Esta métrica se conoce algunas veces como la intensidad de fallos. Tiempo medio entre fallos El tiempo medio entre fallos de sistemas observados. Un MTTF de 500 significa que puede esperarse un fallo cada 500 unidades de tiempo. Disponibilidad La probabilidad de que el sistema esté disponible para su utilización en un momento determinado. Una disponibilidad de 0,998 significa que el sistema es probable que esté disponible durante 998 de cada 1000 unidades de tiempo.

PROBABILIDAD DE FALLOS EN LA PETICIÓN.  Esta métrica es la mas adecuada para sistemas en lo que los servicios se demanda a intervalos de tiempo impredecibles o relativamente largos y en los que existen serias consecuencias si el servicio pedido no se proporciona. Se podría utilizar para especificar sistemas de protección como la fiabilidad de un sistema de liberación de presión en una planta química o el sistema de apagado de emergencia en una planta de energía.

TASA DE OCURRENCIA DE FALLOS  Esta métrica debería utilizarse en donde se hagan peticiones regulares de los servicios del sistema y en donde sea importante que estos servicios se proporcionen correctamente. Debería utilizarse en la especificación de un sistema de cajero automático que procesa transacciones de clientes o en un sistema de reservas de hoteles.

TIEMPO MEDIO ENTRE FALLOS.  Esta métrica debería utilizarse en sistemas con transacciones largas; esto es, en donde la gente utiliza el sistema durante largos periodos de tiempo. El MTTF debería ser mayor que la longitud media de cada transacción.

DISPONIBILIDAD.  Esta métrica debería utilizarse en sistemas que no se detienen y en los que los usuarios esperan que el sistema proporcione un servicio continuado. Ejemplos de tales sistemas son los sistemas de centralita telefónica y sistemas de señalización ferroviaria.

MEDICIONES  Hay tres tipos de mediciones que pueden realizarse cuando se valora la fiabilidad de un sistema: 1. El número de fallos del sistema dado un número de peticiones de servicios del sistema. Se usa para medir el POFOD. 2. El tiempo (o número de transacciones) transcurrido entre fallos del sistema. Se utiliza para medir el ROCOF y el MTTF 3. El tiempo consumido en reparar o reiniciar el sistema cuando ocurre un fallo. que el sistema debe estar disponible continuamente, éste se utiliza para medir el AVAIL  Las unidades tiempo que se pueden utilizar en estas métricas son fechas de calendario, tiempo de procesador o algunas unidades discretas, como por ejemplo el número de transacciones.

CONCLUSIONES  La elección de qué métrica debería utilizarse depende del tipo de sistema sobre el que se aplica y de los requerimientos del dominio de la aplicación.  La utilización de métricas en la fiabilidad del sistema nos permite darle madurez a este para obtener una cobertura adecuada de los fallos y pruebas que se le han realizado.  La fiabilidad de los sistemas debería especificarse como un requerimiento no funcional el cual se exprese de forma cuantitativa utilizando una de las métricas definidas anteriormente.

RECOMENDACIONES  Utilizar las métricas adecuadas para evaluar el sistema con el fin de no tener especificaciones de fiabilidad subjetivas y no formales.  Es necesario y cada vez más importante añadir estos procesos de cálculo de fiabilidad del software y poco a poco se va engranando dentro del proceso normal de desarrollo de software con un ciclo más.