¿El análisis de sistemas no era suficientemente bueno? ¿Era realmente necesaria una nueva sub-disciplina como la ingeniería de requisitos? Parte de la respuesta hay que encontrarla en la comunidad académica. El análisis de sistemas está profundamente enraizado con los sistemas de información, una comunidad centrada en las metodologías y el modelado conceptual, de modo que probablemente el concepto de análisis de los requisitos surgió ligado a los esquemas tradicionales de descomposición funcional top-down. Los requisitos eran capturados y listados como objetivos del usuario, y después elaborados como un conjunto de funciones representados en diagramas de flujo de datos, procesos SADT o cualquier otra técnica de modelado.

El enfoque de los métodos estructurados para el análisis de requisitos fue desafiado en los 80 por las técnicas JAD (Joint Applications Development, Desarrollo Conjunto de Aplicaciones en español) (DSDM Consortium, 1995), que trataron de superar el incómodo y lento proceso de modelado involucrando a los usuarios en el diseño a través de reuniones, tormentas de ideas y escenarios. El enfoque del análisis funcional top-down sería también desafiado por la comunidad partidaria de la orientación a objetos, más inclinada por modelar el dominio del problema antes que establecer objetivos y funciones. Esto allanó el camino a la generación actual de métodos orientados a objetos: ingeniería de sistemas orientados a objetos (Jacobson et al., 1992), la técnica de modelado de objetos (Rumbaugh, 1991) y el análisis y el diseño orientados a objetos (Coad y Yourdon, 1991), sólo por citar algunos. Más recientemente, la comunidad de la orientación a objetos definió un estándar de desarrollo con la creación de UML y del Proceso Unificado, aunque sin aportar nada en cuanto al análisis de requisitos más allá de los casos de uso y escenarios.

La otra influencia de la ingeniería de requisitos la encontramos en la ingeniería del software, una comunidad tradicionalmente interesada en la especificación formal y en la entrega de productos software fiables, a menudo para sistemas de telecomunicaciones en tiempo real y aplicaciones críticas. Los ingenieros de software se encontraron con que, a pesar de contar con detalladas especificaciones formales, algunos sistemas no eran aceptados o fallaban en circunstancias que no habían podido predecirse.

La ingeniería de requisitos ha crecido a partir de estas áreas, a las que además ha contribuido de manera muy significativa. Asimismo, se ha centrado en investigar técnicas y herramientas que complementen los métodos de ingeniería del software.

La fundación de la ingeniería de requisitos puede encontrarse en una colección de artículos (Thayer y Dorfman, 1990) y ediciones especiales de Transactions on Software Engineering (IEEE-TSE, 1991) (Davies y Hsai, 1994), seguidos por las conferencias del IEEE (Filkenstein y Fickas, 1993). Estos eventos revelaron una importante diversidad de temas de investigación y prácticas industriales que estaban más relacionados con el qué construir que con el cómo construirlo. En 1993 Lubas, Potts y Ritcher (Lubars et al., 1993), en el marco de una investigación sobre las prácticas de ingeniería de requisitos en las empresas, expusieron que los requisitos ambiguos y cambiantes constituían un problema constante y que los desarrolladores preferían soluciones organizacionales antes que tecnológicas para hacer frente a los problemas relacionados con la ingeniería de requisitos. Más recientemente, algunos estudios de campo (El Emam y Madhavji, 1995) han determinado que la falta de personal cualificado y los métodos inadecuados son responsables de posteriores defectos en los sistemas.

Referencias

Para terminar, algunas referencias bibliográficas interesantes que he citado durante el post:

Coad, P., y Yourdon, E. E. (1991). Object-oriented analysis. Englewood Cliffs, NJ: Yourdon Press.

Davies, A. M., y Hsai, P. (1994). Proceedings IEEE International Conference on Requirements Engineering .

De Marco, T. (1978). Structured analysis and systems specification. Englewood, NJ: Prentice Hall.

Downs, E., Clase, P., y Coe, I. (1992). Structured systems analysis and design method: Application and context (2ª edición ed.). Nueva York: Prentice Hall.

DSDM Consortium. (1995). Dynamic Systems Development Method.Farnham Surrey: Tesseract Publishers.

El Emam, K., y Madhavji, N. H. (1995). A field study of requirements engineering practices in information systems development. Proceedings on 1995 IEEE International Symposium on Requirements Engineering (RE95) .

Filkenstein, A. C., y Fickas, S. (1993). Proceedings on 1993 IEEE International Symposium on Requirements Engineering (RE93).

Lubars, M., Potts, C., y Ritcher, C. (1993). A review of the state of the proactive in requirement modeling. Proceedings 1st International Symposium on Requirements Engineering.

Ross, D. T., y Schoman, K. E. (1977). Structured analysis for requirements definition. IEEE Transactions on Software Engineering (3), 23-47.

Rumbaugh, J. (1991). Object oriented modelling and design. Englewood Cliffs, NJ: Prentice Hall.

Thayer, y Dorfman. (1990). Systems and Software Requirements Engineering. IEEE.

Los cimientos no son importantes sólo en la arquitectura. Desde los años 70 se sabe que el coste de reparar un defecto una vez entregado el producto software es entre 60 y 100 veces superior al coste que hubiera representado el mismo cambio durante las fases tempranas del proyecto. Este hecho, verificado de forma independiente y empírica por Fagan (Fagan, 1997), Boehm (Boehm, 1977) y Daly (Daly, 1977), confirma la necesidad de un enfoque de calidad en las primeras fases del proyecto, relacionadas generalmente con la obtención y especificación de los requisitos del sistema.

Es la economía, estúpido

Aunque las tareas relativas a ingeniería de requisitos suponen entre el 10 y el 15 por ciento del coste medio del desarrollo de un sistema, las consecuencias de una captura de requisitos defectuosa pueden tener un impacto extremadamente alto. El coste de corregir un error es proporcional al tiempo que permanece sin ser detectado: modificar un requisito apenas requiere editar una o dos líneas en lenguaje natural; alterar el diseño implica revisar las especificaciones y comprobar las ramificaciones de los nuevos requisitos; modificar el código significa malgastar el tiempo de los programadores y la realización de cambios que podrían desestabilizar el diseño.

Existen multitud de estudios que demuestran la incidencia directa de las tareas de ingeniería de requisitos en la calidad final del software desarrollado (Bernárdez, 2003). En los años 80, De Marco y Filkelstein estudiaron las causas de los errores encontrados en los sistemas software, encontrando que sólo el 7% de los errores se producía en la fase de implementación, mientras que el 56% del total tenía su origen en la fase de ingeniería de requisitos.

En 1993, durante una investigación sobre la seguridad en los sistemas de control de las sondas espaciales Galileo y Voyager, Robin R. Lutz concluyó (Lutz, 1993) que una de las principales causas de errores era la existencia de requisitos incorrectos, no documentados o desconocidos.

El coste de omitir la ingeniería de requisitos es alto. No sólo porque los sistemas puedan fallar, sino porque pueden no aprovecharse correctamente o resultar bastante más caros de lo estrictamente necesario: estudios sobre sistemas bancarios muestran que los usuarios sólo utilizan el 30 por ciento de las funciones proporcionadas (Eason, 1988). Las clásicas historias sobre fallos catastróficos y espectaculares apuntan a menudo a errores en las especificaciones de requisitos, o al simple hecho de no haber llevado a cabo ningún intento serio por capturar las necesidades de los usuarios. ¿Se trata simplemente por ello de un problema de motivación y educación? Aunque no resulten tan espectaculares como los desastres, muchos sistemas han sido desarrollados satisfactoriamente, y hoy en día la mayoría de empresas dispone de sistemas automáticos para gestionar partes de su negocio.

Caminar sobre el agua

La verdadera clave del problema hay que buscarla en el cambio. Si las organizaciones mantuvieran siempre los mismos procedimientos y el mundo permaneciera inalterable, la gestión de los requisitos sería muy sencilla, aunque de hecho no lo es: los directivos necesitan mejorar las prácticas de la organización, los gobiernos cambian los impuestos, las empresas necesitan responder a los desafíos de la competencia… La consecuencia más inmediata de esto es que rara vez se puede decir que los requisitos están terminados, así que los desarrolladores están condenados a disparar a un objetivo en movimiento.

En 1996, el ESI (Instituto Europeo del Software, European Software Institute), publicó los resultados de una encuesta realizada a empresas europeas en el marco del proyecto ESPITI (European Software Process Improvement Training Initiative). Según las conclusiones del estudio posterior, los ingenieros de software encuentran las mayores dificultades durante la especificación y la gestión de requisitos. El resto de las fases de desarrollo presentaban, en la mayoría de los casos, problemas menores poco significativos.

La ingeniería de requisitos nos ayuda a construir cimientos sólidos para nuestro software, enfocándose en un área fundamental: la definición de lo que se desea desarrollar. Para ello, nos permite diseñar especificaciones concretas que describan con claridad, sin ambigüedades, de forma consistente y compacta las necesidades de los promotores de un sistema. Una especificación correcta de requisitos formará una base sólida sobre la que podamos levantar un edificio con garantías. Según G. Ñistal, “la calidad no puede implementarse al final del desarrollo o en las etapas finales de los procesos de desarrollo sino que es una característica intrínseca al propio producto. La carrera de la calidad debe iniciarse en las especificaciones de los productos, continuando en las fases posteriores…” (Ñistal, 1999).

La ingeniería de requisitos permite asimismo gestionar las necesidades del proyecto de forma estructurada, mejora la capacidad de realizar una planificación temporal del proyecto, disminuye los costes y retrasos del proyecto, y en general incrementa la calidad del software, facilita la comunicación entre el equipo y evita rechazos por parte de los usuarios finales.

Invertir en los cimientos al principio ahorrará dinero más tarde, aunque esta tarea no está exenta de problemas: por un lado, los usuarios tienden a descubrir nuevos requisitos justo cuando el analista piensa que tiene todo cuanto necesita. Por otro lado, está el “problema del mundo en movimiento”, comentado con anterioridad. Todo lo que el analista puede hacer es intentar obtener la mejor fotografía posible del mundo cuando realiza la captura de requisitos, tratar de anticipar el futuro y diseñar software que sea flexible y pueda adaptarse a los cambios. Aunque como recuerda Alistair Sutcliffe en (Sutcliffe, 2002), anticipar el futuro sea un arte oscuro.

Referencias

Algunos artículos interesantes que he citado:

Bernárdez, B. (2003). Una Aproximación Empírica a la Verificación de Especificaciones de Requisitos para Sistemas de Información. Sevilla. Universidad de Sevilla.

Boehm, B. W. (1977). Some Experience with Automated Aids to the Design of Large-Scale Reliable software. IEEE Transactions on Software Engineering-
Daly, E. (1977). Management of Software Development. IEEE Transactions on Software Engineering.

Fagan, M. (1997). Design and Code Inspections and Process Control in the Development of Programs. IBM.

Lutz, R. R. (1993). Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. Proceedings of IEEE International Symposium on Requirements Engineering.

Ñistal, G. (1999). Calidad del software, punto de vista y experiencias de la Administración Pública. Novática (137), 50-53.

Sutcliffe, A. (2002). User-centred requirements engineering. Springer.

Just add to the field tag:

:autocomplete => 'off'

For example:

 'off' %>

This adds the parameter autocomplete=”off” to the HTML tag.

Como queda bastante claro, Rails utiliza una única tabla donde almacena juntos los atributos de todos los objetos participantes en la jerarquía de herencia. Este enfoque puede ser válido para una jerarquía de clases en la que las subclases no añaden muchos atributos, limitándose a modificar aspectos relativos al comportamiento. Pero para jerarquías grandes con muchos atributos puede generar tablas más grandes de lo recomendable (y con más espacio vacío que información), por lo que lo veo poco generalizable.

¿Alternativas? El enfoque más natural desde el punto de vista de la orientación a objetos consiste en utilizar asociaciones polimórficas, a través de relaciones de tipo has_many :through, especificando una relación entre las una subclase y otra a través de la superclase de la segunda.

Interesante…

The correct configuration for application.ini (at least in my computer) is:

resources.db.adapter = "PDO_MYSQL"
resources.db.params.host = "localhost"
resources.db.params.username = "root"
resources.db.params.password = "root"
resources.db.params.port = "8889"
resources.db.params.dbname = "zf_quickstart"
resources.db.isDefaultTableAdapter = true

Note that is necessary to specify the port in a separate field. The next configuration will not work:

resources.db.params.host = "localhost:8889"

Anyway, if you find errors with the database connection (something so descriptive like “Application error”), adding the following line to the Bootstrap.php file can be useful:

Zend_Controller_Front::getInstance()->throwExceptions(true);

Before placing the line above I was getting the error: “PHP Fatal error:  Uncaught exception ‘PDOException’ with message ‘SQLSTATE[HY000] [2005] Unknown MySQL server host ‘localhost:8889′”.

Good luck!

rake doc:plugins:file_column

Escribo esto fundamentalmente para futuras referencias. Es una de esas cosas que he aprendido y olvidado ya unas cuantas veces y no quiero tener que volver a buscarlo.

El problema es que, acostumbrado a trabajar con el Proceso Unificado, mi cerebro ha quedado irremisiblemente incapacitado para pensar en cualquier otra metodogía, y precisamente este proceso se demuestra bastante inútil para dirigir un desarrollo basado en un framework como Ruby on Rails: por ejemplo, una vez que defines los escenarios y el modelo de análisis, no hace falta un modelo muy detallado del diseño (donde incluiríamos, por ejemplo, las clases encargadas de recuperar los datos de la base de datos, con un patrón DAO o lo que fuera preciso…), pues la mayoría de los frameworks están orientados al patrón MVC y si algo hacen es encapsular el acceso a datos. El caso es que la distancia entre el papel y el código es algo menor, y obviamente necesitas un proceso que refleje esta circunstancia.

Otro problema añadido es que la mayoría de las metodologías ágiles están centradas en un tipo muy concreto de equipo, y definen roles específicos para los diferentes miembros. Siendo este un desarrollo que voy a acometer en solitario, necesitaba también un proceso que no se centrara demasiado en los roles, o que al menos no los identificara directamente con perfiles empresariales.

Añadiré a la lista de problemas que cuando leo un artículo presentando una metodología ágil tengo la extraña sensación de que se están riendo de mí. Es como ver a Epi y Blas explicándote cómo desarrollar un proyecto. Es todo tan positivo, rápido, sencillo y cool, que acabo poniéndome nervioso. Pero bueno, eso es algo puramente personal.

No quiero distraerme. El caso es que buscando, encontré una adaptación del Proceso Unificado para entornos de desarrollo ágiles que creo que es precisamente lo que necesito. El proceso se centra en el modelado y en la implementación, prestando especial relevancia a las pruebas, lo cual me parece interesante porque es precisamente donde pone el énfasis Ruby on Rails. La adaptación en concreto se denomina Agile Unified Process (era totalmente imprevisible) y bueno, parece que no hay mucha información al respecto, pero he encontrado algunos artículos que parecen interesantes. Si descubro algo más lo comentaré por aquí.

También me ha gustado mucho Agile Web Development with Rails, que explica los mismos conceptos desde un punto de vista más general, con lo que resulta un buen complemento para el primero. Hay que decir que ambos tienen una metodología muy sencilla y muy centrada en la práctica, abordando este último libro el desarrollo de una tienda virtual bastante completa que sirve como marco para captar muchas de las sutilezas del lenguaje.

Creo que el siguiente paso está claro: empezar a escribir código por mis propios medios de una vez :-)