¿Cómo evalúa la confiabilidad en el software?

Question

Actualmente estamos estableciendo los criterios de evaluación para un estudio comercial que realizaremos.

Uno de los criterios que seleccionamos es la confiabilidad (y / o robustez, ¿son iguales?).

¿Cómo evalúa que el software es confiable sin poder dedicar mucho tiempo a evaluarlo?

Editar: siguiendo las líneas de la respuesta dada por KenG, para reducir el enfoque de la pregunta: Puede elegir entre 50 soluciones de software existentes. Debe evaluar qué tan confiables son, sin poder probarlos (al menos inicialmente). ¿Qué métricas tangibles u otras pueden usar para evaluar dicha confiabilidad?

Answer 1

La fiabilidad y la solidez son dos atributos diferentes de un sistema:

Confiabilidad

  

El IEEE lo define como " ;. . . la   capacidad de un sistema o componente para   realizar sus funciones requeridas bajo   condiciones establecidas para un determinado   período de tiempo. "

Robustez

  

es robusto si continúa funcionando a pesar de anormalidades en la entrada, cálculos, etc.

Entonces, un sistema confiable realiza sus funciones tal como fue diseñado dentro de las limitaciones; Un sistema robusto continúa funcionando si ocurre lo inesperado / no anticipado.

Si tiene acceso a cualquier historial del software que está evaluando, se puede inferir alguna idea de confiabilidad a partir de los defectos reportados, el número de lanzamientos de 'parches' a lo largo del tiempo, incluso el abandono en la base del código.

¿El producto tiene procesos de prueba automatizados? La cobertura de prueba puede ser otra indicación de confianza.

Algunos proyectos que utilizan métodos ágiles pueden no ajustarse bien a estos criterios: se esperan lanzamientos frecuentes y muchas refactorizaciones

Consulte con los usuarios actuales del software / producto para obtener información del mundo real.

Answer 2

Bueno, la palabra clave 'confiable' puede conducir a respuestas diferentes ... Cuando pienso en la confiabilidad, pienso en dos aspectos: 1 ~ siempre dando la respuesta correcta (o la mejor respuesta) 2 ~ siempre dando la misma respuesta

De cualquier manera, creo que se reduce a algunas pruebas repetibles. Si la aplicación en cuestión no está construida con un conjunto de cadenas de pruebas unitarias y de aceptación, aún puede crear un conjunto de pruebas manuales o automáticas para realizar repetidamente.

El hecho de que las pruebas siempre devuelvan los mismos resultados mostrará que se cuida el aspecto # 2. Para el aspecto # 1, realmente depende de los escritores de pruebas: proponer buenas pruebas que expongan errores o imperfecciones.

No puedo ser más específico sin saber de qué se trata la aplicación, lo siento. Por ejemplo, un sistema de mensajería sería confiable si los mensajes siempre se entregan, nunca se pierden, nunca contienen errores, etc., etc. La definición de confiabilidad de una calculadora sería muy diferente.

Answer 3

Hable con las personas que ya lo usan. Puede probar su confiabilidad, pero es difícil, costoso y puede ser muy poco confiable dependiendo de lo que esté probando, especialmente si tiene poco tiempo. La mayoría de las empresas estarán dispuestas a ponerlo en contacto con los clientes actuales si esto le ayuda a venderle su software y podrán darle una idea del mundo real de cómo se maneja el software.

Answer 4

Depende del tipo de software que esté evaluando. El criterio principal (y quizás solo) de confiabilidad de un sitio web podría ser su tiempo de actividad. NASA tendrá una definición completamente diferente para la confiabilidad de su software. Su definición probablemente estará en algún punto intermedio.

Si no tiene mucho tiempo para evaluar la confiabilidad, es absolutamente crítico que automatice su proceso de medición. Puede utilizar las herramientas integración continua para asegurarse de que solo tenga que encontrar manualmente un error una vez .

Recomiendo que usted o alguien de su empresa lea Integración continua: mejora de la calidad del software y Reducción del riesgo . Creo que ayudará a llevarlo a su propia definición de confiabilidad de software.

Answer 5

Como con cualquier cosa, si no tienes tiempo para evaluar algo tú mismo, entonces debes confiar en el juicio de los demás.

Answer 6

La confiabilidad es uno de los tres aspectos de la efectividad de algunas cosas. Los otros dos son Mantenimiento y Disponibilidad ...

Un artículo interesante ... http://www.barringer1.com/pdf/ARMandC .pdf analiza esto con más detalle, pero en general,

La confiabilidad se basa en la probabilidad de que un sistema se rompa ... es decir, cuanto más probable es que se rompa, menos confiable es ... En otros sistemas (que no sea software), a menudo se mide en el tiempo medio entre Falla (MTBF) Esta es una métrica común para cosas como un disco duro ... (10000 horas MTBF) En software, supongo que podría medirlo en el tiempo medio entre fallas críticas del sistema, o entre fallas de la aplicación, o entre errores irrecuperables, o entre errores de cualquier tipo que impidan o afecten negativamente la productividad normal del sistema ...

La capacidad de mantenimiento es una medida de cuánto tiempo / cuánto cuesta (cuántas horas hombre y / u otros recursos) se necesita para arreglarlo cuando se rompe. En software, podría agregar a este concepto cuánto tiempo / cuán costoso es mejorar o ampliar el software (si ese es un requisito continuo)

La disponibilidad es una combinación de los dos primeros, e indica a un planificador, si tuve 100 de estas cosas funcionando durante diez años, después de calcular las fallas y cuánto tiempo cada unidad fallida no estuvo disponible mientras estaba siendo reparada, reparada , lo que sea, ¿cuántos de los 100, en promedio, estarían en funcionamiento al mismo tiempo? 20% o 98%?

Answer 7

Tendrá que entrar en el proceso entendiendo y aceptando completamente que se comprometerá, lo que podría tener efectos negativos si la confiabilidad es un criterio clave y no tiene (o no está dispuesto a comprometer) los recursos evaluar adecuadamente en función de eso.

Dicho esto, determine cuáles son los requisitos clave que hacen que la confiabilidad del software sea crítica, luego elabore pruebas para evaluar en función de esos requisitos.

La robustez y la fiabilidad se cruzan en su relación entre sí, pero no son necesariamente lo mismo.

Si tiene un servidor de datos que no puede manejar más de 10 conexiones y espera 100000 conexiones, no es robusto. No será confiable si muere a > 10 conexiones. Si ese mismo servidor puede manejar la cantidad de conexiones requeridas pero muere de forma intermitente, se podría decir que aún no es robusto ni confiable.

Mi sugerencia es que consulte con una persona de control de calidad con experiencia que tenga conocimiento en el campo para el estudio que llevará a cabo. Esa persona podrá ayudarlo a idear pruebas para áreas clave, atentamente dentro de sus limitaciones de recursos. Recomiendo un tercero neutral (en lugar del escritor o proveedor de software) para ayudarlo a decidir sobre las características clave que deberá probar para tomar su determinación.

Answer 8

Si no puede probarlo, tendrá que confiar en la reputación de los desarrolladores junto con lo bien que siguieron las mismas prácticas en esta aplicación que sus otras aplicaciones probadas. Ejemplo: Microsoft no hace un muy buen trabajo con la versión 1 de sus aplicaciones, pero 3 & amp; 4 suelen ser bastante buenos (Windows ME era la versión 0.0001).

Answer 9

Dependiendo del tipo de servicio que está evaluando, puede obtener métricas de confiabilidad o SLI - indicadores de nivel de servicio - métricas que capturan qué tan bien está funcionando el servicio / producto. Por ejemplo, procese el 99% de las solicitudes en 1 segundo.

Con base en el SLI, puede configurar acuerdos de nivel de servicio: un contrato entre usted y el proveedor de software sobre qué SLO (objetivos de nivel de servicio) le gustaría con las consecuencias de que ellos no los entreguen.