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

Question

Actualmente estamos estableciendo los criterios de evaluación para un estudio comercial que llevaremos a cabo.

Uno de los criterios que seleccionamos es la fiabilidad (y/o la solidez: ¿son los mismos?).

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

Editar: En la línea 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é tangible métricas u otras puede usar para evaluar dicha confiabilidad?

Answer 1

La fiabilidad y la robustez son dos atributos diferentes de un Inglés:

Reliability

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

Robustness

es robusta si continúa funcionando a pesar de las anomalías en la entrada, cálculos, etc.

lo tanto un sistema fiable realiza sus funciones, ya que fue diseñado para dentro restricciones; Un sistema robusto continúa funcionando si ocurre algo imprevisto/imprevisto.

Si tiene acceso a cualquier historial del software que está evaluando, se puede inferir cierta idea de confiabilidad a partir de los defectos informados, el número de versiones "parcheadas" a través del tiempo e incluso el abandono del código base.

¿El producto tiene procesos de prueba automatizados? La cobertura de la prueba puede ser otra indicación de confianza. Se espera que los lanzamientos frecuentes y una gran cantidad de refactorización

Comprobar con los usuarios actuales del software/producto para obtener información del mundo real -

Algunos proyectos utilizando métodos ágiles pueden no encajar bien con estos criterios.

Answer 2

Bueno, la palabra clave 'confiable' puede llevar a respuestas diferentes ... Cuando pienso en la fiabilidad, pienso en dos aspectos: 1 ~ siempre dando la respuesta correcta (0 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 series de unidades y pruebas de aceptación, aún puede obtener un conjunto de pruebas manuales o automáticas para realizar de forma repetida.

El hecho de que las pruebas siempre devuelvan los mismos resultados mostrará que el aspecto # 2 está resuelto. Para el aspecto n. ° 1, realmente corresponde a 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 se entregan siempre, nunca se pierden, nunca contienen errores, etc. etc. La definición de confiabilidad de una calculadora sería muy diferente.

Answer 3

Habla con personas que ya lo están usando. Puede probarse la confiabilidad, pero es difícil, costoso y puede no ser confiable según 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 le ayudará a vender su software y podrán darle una idea real de cómo funciona el software.

Answer 4

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

Si usted no tiene mucho tiempo para evaluar la fiabilidad, es absolutamente crítico que automatice el proceso de medición. Puede usar las herramientas continuous integration para asegurarse de que solo tiene que encontrar manualmente un error una vez.

Le recomiendo que usted o alguien de su empresa lea Continuous Integration: Improving Software Quality and Reducing Risk. Creo que ayudará a guiarlo a su propia definición de confiabilidad del software.

Answer 5

Tendrá que entrar en el proceso comprendiendo y aceptando plenamente que hará un compromiso, lo que podría tener efectos negativos si la confiabilidad es un criterio clave y no tiene (o no está dispuesto a comprometerse) recursos para evaluar apropiadamente en base a eso.

Habiendo dicho eso, determine cuáles son los requisitos clave que hacen que la confiabilidad del software sea crítica, luego diseñe pruebas para evaluar según esos requisitos.

Robustez y fiabilidad 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 en> 10 conexiones. Si ese mismo servidor puede manejar la cantidad de conexiones requeridas pero muere intermitentemente, podría decir que todavía no es robusto y no confiable.

Mi sugerencia es que consulte a una persona con experiencia en el control de calidad que tenga conocimientos en el campo para el estudio que va a realizar. Esa persona podrá ayudarlo a diseñar pruebas para áreas clave, a su entender, dentro de sus limitaciones de recursos. Recomendaría una tercera parte neutral (en lugar del escritor o proveedor de software) para ayudarlo a decidir sobre las funciones clave que deberá probar para tomar una determinación.

Answer 6

Al igual que con cualquier cosa, si no tiene el tiempo para evaluar algo usted mismo, entonces tiene que confiar en el juicio de los demás.

Answer 7

La fiabilidad es uno de los tres aspectos de la eficacia algos .. Los otros dos son mantenibilidad y disponibilidad ...

un interesante ... http://www.barringer1.com/pdf/ARMandC.pdf discute esto en 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 sean software), a menudo se mide en Mean Time Between Failure (MTBF). Esta es una medida común para cosas como un disco duro ... (10000 hrs MTBF) En software, creo que se podría medir en Mean Tiempo entre fallas críticas del sistema, o entre fallas de aplicaciones, o entre errores irrecuperables, o entre errores de cualquier tipo que impiden o afectan negativamente la productividad normal del sistema ...

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

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

Answer 8

Si no puede probarlo, tendrá que confiar en la reputación del desarrollador (es) junto con qué tan bien siguieron las mismas prácticas en esta aplicación que sus otras aplicaciones probadas. Ejemplo: Microsoft no hace un buen trabajo con la versión 1 de sus aplicaciones, pero 3 & 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á el servicio/producto. Por ejemplo, procese el 99% de las solicitudes en 1 segundo.

Basado 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) desea con las consecuencias de que no los entreguen.