Hace unas semanas, Juan Pablo Picasso (Socio de Andina Software y Profesor de TADP) envió un mail a una lista iniciando una discusión sobre que realmente es la Robustez. En este post explico lo que para mí es la robustez y por que.
Me inclinaría por una definición como la siguiente para la robustez:
"Es el grado de percepción/sensación que da una aplicación para responder a eventos no contemplados o que exceden los requerimientos no funcionales y que su respuesta permita medirse en parametros calculables, o sea, no ocurra un desastre"
No estoy seguro si se entendió, pero me gustaría dar algunos ejemplos. Si tenemos un NFR de Performance como el siguiente
"El sistema debe poder responder a 1000tx por Hora con un tiempo de respuesta menor a 5 segundos para las transacciones Tx1 y Tx2",
Podríamos pensar en que la robustez entraría en juego en casos en los cuales si hay 1001tx por hora el sistema responda de manera aceptable y que no se caiga Obviamente podriamos pensar que no se va a cumplir con los 5 segundos, pero tampoco que no se cumpla por mucho, o sea, que responda en 6 o un poco más... se entiende el ejemplo?
Lo mismo pasa con la robustez para los Atributos de Calidad No runtime, en donde vos tenes algun NFR de modificabilidad definido, por ejemplo:
"El sistema debe permitir la modificación de parámetros la interfaces X e Y a pedido del usuario y debe ponerse en producción en un tiempo de 40 días, incluyendo el analisis, diseño, desarrollo, testing y deploy",
Y si te llega algún Change Request, que pide dentro de la modificación de parámetros de las interfaces X e Y, y aparte agregar una exception, como notaran, la exception no está contemplada, en este caso la robustez entra en juego por el lado de esa misma sensación de que si no la habias contemplado el cambio se puede realizar bajo parametros decentes.
Por la tanto ya sea para Atributos de Calidad Runtime y No Runtime la robustez se podria pensar como ese grado de sensación ortogonal a cualquier tipo de Atributo de Calidad que mide el grade poder responder con parámetros decentes.
Esta es una conclusión personal después de haber discutido con varios profesionales sobre este tema. Principalmente con Gonzalo De Pedro y Nicolas Passerini.
Opiniones?
Suscribirse a:
Comentarios de la entrada (Atom)
3 comentarios:
Recuerdo haber hablado muchas veces con vos Gustavo sobre este tema.
No quiero entrar en la discusion si es un Atributo de Calidad o es ortogonal a los mismos. Porque no me siento calificado para clasificar a esto en atributos, y hasta descreo un poco de esa clasificacion.
Lo que si te puede dejar mi opinion sobre que es la robustez.
En mi opinion la robustez tiene que ver con el comportamiento del sistema cuando se encuentra ante una situacion anormal. Es decir, que la robustez podria entenderse como el grado de certeza que se tiene sobre el comportamiento del sistema ante un evento inesperado o poco probable.
Siguiendo con tus ejemplos, en el caso de un NFR que se refiera a la cantidad de tx por unidad de tiempo, se podria esperar que el sistema al encontrar mas transaccciones de las esperadas se comporte de diferentes maneras, pero cuanto mas seguro se este de como se comportara mas robusto es el mismo, si el sistema deja de funcionar y atender transacciones porque se sobrecarga y este comportamiento no es el esperado y no se tomo ninguna medida para prevenir esto se puede decir que el sistema es poco robusto, por otro lado si el sistema no atiende a la transaccion n+1 (siendo n el limite de transacciones) y este es un comportamiento esperado el sistema es mas robusto. Notese que no tiene que ver con el comportamiento que tiene el sistema, sino con el grado de certeza con el que podemos asegurar que se vaya a comportar asi, si como medida de proteccion estuviera contemplado que el sistema se apagara al recibir mas transacciones de las pedidas no se podria objetar el grado de robustez porque se dejo de atender transacciones, porque el sistema se comporta como fue previsto.
La robustez tiene que ver con la seguridad que se tenga del comportamiento del sistema ante eventos inesperados. Seguramente algunos sistemas tienen partes de su funcionamiento criticas que no pueden ser detenidas de forma abrupta por un cambio inesperado del entorno, en este caso la robustez es crucial, hay que pensar el sistema para que siga realizando esa funcion, por ahi degradando o cancelando otras funciones ante cualqueir evento externo.
Es parecido a lo que seria la robustez no runtime. En el articulo se habla de un CR que afecte un NFR de modificabilidad. En este caso, en mi opinion la robusteza pasaria por poder predecir certeramente cuanto esfuerzo extra demandaria este cambio, es decir que se pueda predecir el impacto del cambio. Tal vez se desee que el esfuerzo varie de forma lineal con la cantidad de interfaces que cambian, de esta manera un cambio chico en las interfaces producira un cambio pequeño en el esfuerzo y un comportamiento no lineal en esta funcion seria un signo de baja robustez. Pero nuevamente, sea cual sea el comportamiento esperado ante un cambio de interfaces me parece que pasa mas por la capacidad para predecirlo.
Llevandolo por ahi mas al mundo fisico, tomemos por ejemplo una parte metalica de un sistema mecanico, esta parte no es robusta porque soporte mas esfuerzo del esperado, sino que la robustez pasa por saber que en caso de que se someta a mas esfuerzo del esperado se rompera de una manera calculada afectando lo menos posible al sistema. Creo que eso es la robustez.
Desde ya que no me parece apropiado hablar de 'sensacion', eso me suena mas a algo empirico, lo cual puede ser suficiente en algunos casos, pero cuando la robustez sea realmente fundamental para el exito del sistema, tomemos por ejemplo sistemas de tiempo real, o de control, donde un comportamiento erratico puede siginificar daños a bienes o la perdida de vidas humanas el asegurarse que el comportamiento sea predecible ante situaciones no calculadas es crucial y debe ser medido tenido en cuenta durante todo el diseño y la construccion del sistema, debe ser medido y validado correctamente. Por supuesto que podemos trasladar esto a las aplicaciones empresariales en la que un comportamiento esperado signifique una perdida mayor al esfuerzo que significa prestar la atencion necesari a la robustez. Pero esto ya hace al famoso anilisis de costo/beneficio.
Será que soy un pragmático picapiedrero.
Robustez /robussste'/ -- adj:
1. que no se cuelga bajo ninguna circunstancia.
2. que se banca cuanto fuzzer haya por ahí, sin volar por los aires al grito de "Segmentation fault".
3. que las posibilidades más estrambóticas tienen un "case" en el código.
4. que no conoce lo que es un DoS.
y si.... si algo es de calidad... es robusto
Aparentemente los argumento para definir los atributos de calidad pueden estar algo confusos en lo que a robustez se refiere. Me acoplo mejor a las mediciones empíricas que a las apreciaciones subjetivas reconociendo que hay relaciones directar e inversas entre distintos atributos para lograr definir un índice de robustez. No adopto las limitaciones que justifica a la robustez solo el comportamiento del sistema fuera de los límites, ya que esto acota mucho el critrio.
Yo particularmente ligo Robustez con Integridad como hojas de un troncal llamado Fiabilidad, el cual es hoja de un troncal llamado Usabilidad que proviene de una raíz llamada Utilidad General (modelo de Boehm)por lo que es más importante medir el grado de fiabilidad lo cual no puede ser obtenido por relación directa con solo esos atributos, sino que por múltiples relaciones inversas con otros atributos que transgreden a estos mencionados, terminan determinando la Utilidad General del sistema.
Saludos,
Javier
www.cbasqa.blogspot.com
Publicar un comentario