Leyendo "Código Completo 2" en un párrafo de Calidad de Requisitos encontré esto:
¿Se especifican compensaciones aceptables entre atributos competitivos, por ejemplo, entre robustez y corrección?
(lo anterior es un punto de una gran lista de casillas de verificación para verificar la calidad de los requisitos)
Entonces, encontré muchas definiciones de Robustez y Corrección, en la web, libros académicos, etc.
p.ej :
En el libro "Construcción de software orientado a objetos, 2ª edición, Bertrand Meyer, Prentice-Hall, 1997":
- Corrección: El grado en que un sistema está libre de [defectos] en su especificación, diseño e implementación.
- Robustez: El grado en que un sistema continúa funcionando en presencia de entradas inválidas o condiciones ambientales estresantes.
A pesar de esto, no está claro por qué y en qué situaciones estos dos podrían estar en conflicto.
Mi pregunta es: ¿por qué estos dos atributos están en competencia ?
Respuestas:
Hay muchas situaciones en las que estos dos podrían estar en conflicto. Por ejemplo, la robustez puede implicar resistencia bajo una carga pesada. Si una respuesta aproximada (es decir, incorrecta) a una solicitud se puede calcular mucho más rápido que una respuesta exacta (correcta), es importante saber si el sistema debe entregar un resultado aproximado o si no puede entregarse por completo.
fuente
Estos dos son solo ejemplos como usted dijo. De hecho, todos los requisitos no funcionales de ese tipo pueden potencialmente entrar en conflicto entre sí. En el libro "Construyendo arquitecturas evolutivas" hay una tabla de aproximadamente un centenar de estas "-ilidades" (como también se las llama a menudo).
Es una especie de ejercicio para los arquitectos de software considerar el posible conflicto entre dos de estos. Básicamente, puede decidir cuáles de estos son importantes para sus proyectos y luego realizar un seguimiento de estos conflictos.
Para volver a su ejemplo preciso y echar un vistazo a la definición del término
robustness
en Wikipedia:Como puede ver en la definición, la robustez implica errores . Por otro lado, desea tener la corrección, lo que básicamente significa la ausencia de errores.
Para hacer más aparente el conflicto, consideremos un campo de entrada simple. Desde el requisito de corrección, es más fácil rechazar cualquier entrada errónea realizada por el usuario. Pero la robustez requiere que pueda trabajar con esta entrada, lo que puede no ser del todo correcto.
Para llevarlo todo a su libro: ¿cuál es la compensación aceptable ahora? Supongamos que escribe una aplicación científica en la que el usuario puede ingresar una cantidad de voltaje, incluida la magnitud. Entonces las entradas correctas serían algo así como "10 kV" o "200 mV". Las compensaciones aceptables pueden incluir entradas permitidas como "10kV", "10kVolt", o incluso solo "10" y, en aras de la corrección, asigne estas a un valor de voltaje válido. Tenga en cuenta que esto sigue siendo una compensación y no una cosa de "lo mejor de ambos mundos". Considere mayúsculas y minúsculas: "10 kV" y "10 KV" pueden estar bien, pero "10 mV" y "10 MV" pueden no estarlo. La corrección se vuelve cuestionable ya que no estás seguro si es mili o mega ahora,
fuente
Un ejemplo práctico es XHTML vs. HTML .
Por lo tanto, XHTML apunta a la corrección, mientras que HTML apunta a la robustez. Actualmente HTML parece más popular, pero ambas partes tienen buenos argumentos.
fuente