Utilizando la Bicing API de Roc Boronat, Bicingstats obtiene regularmente (generalmente cada hora) datos sobre la ocupación de las estaciones, obteniendo el número de bicicletas ancladas y el número de espacios libres. Mantiene también un listado de estaciones disponibles con su posición en coordenadas. El código fuente de Bicingstats es libre y se puede descargar de GitHub.

¿Cuál es la utilidad de todo esto? En general bien poca, si quitamos la diversión de desarrollar la aplicación. Mi idea inicial era poder obtener diagramas de ocupación, como los que se pueden consultar ahora mismo, sólo que con datos promedio:

Del estudio de los datos de ocupación promedio obtener información como la siguiente:

• ¿Qué estaciones se quedan vacías con más frecuencia?
• ¿A qué horas suele quedarse vacía una estación? (y lo más interesante: ¿qué probabilidad hay de que una estación tenga bicicletas disponibles cierto día a cierta hora?)
• ¿Qué estaciones permanecen llenas más horas al día? (impidiendo dejar bicicletas)

Pienso en estos datos como una fuente de información que podría servir para mejorar el servicio y a su vez, como una fuente de datos para otras aplicaciones.

De momento, lo siguiente que me gustaría hacer es una aplicación que me anticipe cada noche qué probabilidades tengo al día siguiente de encontrar una bicicleta cerca de casa, para saber si tengo que levantarme un poco antes para llegar al metro :-P. Combinado con la predicción del tiempo sería simplemente perfecto :-).

git filter-branch --index-filter '
  git rm --cached --ignore-unmatch db/development.sqlite3
'

Very useful :-)

First of all, I needed to set SMTP as prefered delivery method in the application.rb:

# config/application.rb

module MyApp
  class Application < Rails::Application
    ...
    config.action_mailer.delivery_method = :smtp
    ...
  end
end 

And then, I created a smtp.rb initializer (at config/initializers) as follows:

# config/initializers/smtp.rb

ActionMailer::Base.smtp_settings = {
  :address => "smtp.gmail.com",
  :port => 587,
  :domain => 'mydomain.com',
  :user_name => "myaccount@mydomain.com",
  :password  => "mypassword",
  :authentication => 'plain',
  :enable_starttls_auto => true
}

That’s all!

Se trata de una Moleskine normal y corriente, salvo por la particularidad de que la cubierta dispone de un pequeño bloque de Lego. Esto tiene unas cuantas posibilidades. De hecho te permite convertir tu libreta en una nave alien :-P.

Estoy encantado de la vida :-).

¿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…