Competición: Mejor notación para expresar los requisitos del sistema (II)

Hace un tiempo ya mencionamos una competición (a celebrarse en la conferencia RE’09) para encontrar la mejor notación para expresar los requisitos que tiene que cumplir un sistema software. Las candidatas son muchas y variadas:: plain text specifications, structured text templates, goal-oriented requirement approaches (ya sea usando la i* notation ), la USER Requirements Notation ) o el UML.

Esta variedad es lo que motivó a Orlena Gotel y Jane Huang a planear una competición donde “Teams of modelers will be challenged to illustrate the power and flexibility of their favorite approach for requirements modeling, while conference participants will act as the ultimate judges as they vote approaches off the panel round-by-round”

Una vez celebrada ya la competición, es tiempo de saber cuál fue el resultado final. Xavier Franch , líder del grupo GESSI nos hace un resumen (gracias Xavi!):


A vibrant competition was held FOR determining the top model requirements engineering notation. IN the FIRST round, the several teams presented IN one slide-three minutes a model FOR a problem statement given IN advance, an imaginary new version FOR the New York Fire Engine Dispatch System. The applausometer determined that the four finalists were NATURAL LANGUAGE, rich images, URN AND the i* framework. Subsequent rounds incorporated new requirements FROM two stakeholders that just showed up IN the room (two frustrated Shakesperian actors, brilliant Don Gause AND Brian Berenbach). TO make a long story short, NATURAL LANGUAGE AND rich images won ex-aequo the contest. Given the informal AND IN fact comedy-LIKE nature OF the panel, it makes NO sense TO try TO conclude anything. However, it IS TRUE that FOR the two semi-formal notations that passed the FIRST round, adapting ON the fly the model TO the new requirements was tough due TO the difficulty OF presenting the resulting model IN an attractive form FOR the audience AND the need TO use a flip-chart IN the room instead OF SOME supporting modeling tool. Attendees did reward the intuitive understanding OF the new models IN the two informal notations, AND basically this was the main criterion TO decide. The reasoning capability OF the other two MORE formal notations didn’t have a chance to be explored. To sum up, it was a funny exercise but the award is still to be decided.

Por supuesto, estos resultados no son conclusivos pero sí que son muy interesantes. En mi opinión, Xavi tiene razón cuando dice que la gente prefirió las notaciones más informales porque son más fáciles de entender (no hay necesidad de entrenamiento) y más fáciles de cambiar dinámicamente en un tiempo limitado a medida que nos añaden nuevos requisitos. Las ventajas de utilizar una notación más formal (e.j. la capacidad de análisis de la especificación y/o la capacidad de usar esta información para derivar modelos preliminares del sistema) no eran objeto de la comptición con lo que la gente no pudo decidir si el esfuerzo addicional de utilizar este tipo de notaciones vale la pena.

Si te ha gustado esta entrada, puedes subscribirte a este Software Modeling blog y/o seguirme en twitter y/o a través de la lista de distribución del portal Y si realmente te ha gustado ayúdame a hacerlo llegar a otros utilizando los bookmarks que tienes a continuación:

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress