Período investigación

16-07-08

He instalado CouchDB. La instalación en Ubuntu fue relativamente fácil y sin problemas. La interfaz Web está muy bien para poder administrar la base de datos.

Interesante parece también FeatherDB que he encontrado a través de la pagina de BD documentales de wikipedia. Busco el código de la integración Django-CouchDB, pero no está en google-code, donde se supone aloja el proyecto. Buscando un poco, lo encuentro aqui

15-07-08

Mirando de nuevo el tema de los esquemas flexibles encuentro CouchDB, BD escrita en Erlang con bindings para Python. Aparentemente, ya están trabajando en la integración con django. Interesante la pagina en Jaccobian sobre el tema

Ya he empezado a usar Django para implementar el esquema. Lo primero, el esquema de los diagramas UML de Amador es conceptual, pero requiere algunas modificaciones para facilitar su implementación. Si se implementase tal cual, hay problemas con la herencia de SpecificationObject y C_Requirements, por la relación de composición document a SpecificationObject. En este caso, habría que usar Multitable Inheritance.

23-09-07

Hace mucho tiempo no he hecho nada al respecto, aunque en mi actual empresa ha implementado un sistema de control para la certificación ISO 9001 y para el seguimiento de la producción basado en Trac y Django. Aunque Trac en general es muy bueno como gestor de proyecto por el markup de los tickets y la Wiki (referencia de tickets, changesets, etc.) queda patente que hace falta una gestión de requisitos.

Por otra parte, en una jornada de SL en la Admon Pública quedó patente el deseo de poder editar documentos OpenDocument de manera colaborativo con la posibilidad de bloquear partes del documento. Además, no hay integración de OpenOffice.org con SVN. Los archivos se consideran binarios. La Oficina de Calidad de CICE para la orden INNOVAL (Incentivos para la modernización de administraciones locales) obliga usar OpenDocument (ISO 26300) y otros organismos usan procesadores de texto para crear documentos de requisitos. Pero eso es un infierno.

Además, hace falta que los requisitos sean accesibles desde el gestor de proyectos para ver el estado de aprobación, implementación, validación, etc. Los requisitos, así como otros artefactos parecen ser datos estructurados en mayor grado con una posible representación.

Con todo ello parece que lo óptimo sería una aplicación que permitiese integrar los contenidos en documentos OpenDocument y a su vez se integrase bien con el gestor de proyecto (en nuestro caso Trac). Además deseamos una cosa muy simple.

Esto me lleva a pensar en una **aplicación Web con interfaz http y xml* (html, rss, etc.) con la posibilidad de incluir sus datos desde OpenOffice.org* o cualquier otro procesador de textos. Además, favorece la separación entre datos+lógica y representación. Respecto al esquema, podría ser semi relacional y semi flexible (datos persistidos mediante xml en un campo de texto). Lo que no sé cómo es cómo pueden convertirse los xml en tablas. (Lo suyo sería alguna macro de OpenOffice.org o alguna transformación XSLT.)

El problema se presenta a la hora de "meterle" mano con una hija recién nacida.

22-03-07 Alternativas compartición de datos / subversion

Escenario: varias personas en el mismo servidor de aplicaciones vs copias independientes

20-02-07 Brainstorming requisitos nueva generación herramientas REM

Esto son ideas, no significa que posteriormente se implementen.

• instalación stand-alone para realización de prácticas de estudiantes de informática en su casa:
  • framework ligero: ha de poder ejecutarse en máquinas de no muy altas prestaciones. Plone es un tanto pesado, muchas de las plataformas Java también. Sería mejor algo más ligero tipo Django, Drupal, etc.
  • packaging: instalador
• instalación centralizada: repositorio de documentos REM
• multi-plataforma: al menos Linux y Windows
• esquemas flexibles: sería bueno poder definir el esquema de requisitos usado para cada proyecto. Además del esquema ya exsitente en REM (actual), interesan específicos para
  • Servicios Web: calidad del servicio: tiempos de respuesta, disponibilidad, horarios, constraints
  • Sistemas navegacionales: requisitos específicos, como accesibilidad, nº de pasos, etc.
  • Pruebas: valores de ejemplo típicos, valores máximos/mínimos

  Amador habló de XSchema. Una posibilidad sería usar un documento XML y atacarlo mediante DOM y realizar la validación a posteriori. ¿Cómo se tratan cambios de esquemas?

• texto enriquecido: cursiva, negrita, subrayado, imágenes, hipervínculos. No permitir todo, pero lo necesario para poder enfatizar términos, etc. (ej. DocBook)
• salida formato con definición de cabeceras de páginas, índices, etc. (ej. PDF, OpenDocument) y HTML / xHTML
• sincronización documentos para permitir el trabajo off-line: ej. con repositorio subversion en el nodo maestro, y clientes subversion en los demás nodos.
• integración con herramientas UML: importación / exportación XMI: ver esquemas XMI de casos de uso. ver si es viable y posible
• mejorar uso y gestión de patrones lingüísticos:
  • permitir elegir uno u otro en los requisitos
  • permitir al usuario agregar nuevos patrones
• workflow requisitos y documento: borrador -> pdte verificación -> pdte validación -> aprobado (-> implementado -> testado)
• workflow flexibles, dependiendo de proceso software en empresa
• trazabilidad de las modificaciones (mediante subversion o log)
• staging: congelación de las versiones aprobadas de los requisitos.
• integración: acceso mediante Web Services (para lectura y escritura)
• interfaz Web experimental (AJAX?)

04-10-06 Buscando opciones de esquemas flexibles

En la búsqueda de la posibilidad de tener esquemas flexibles para la elicitación de requisitos se me ocurren las siguientes ideas:

• base de datos relacional, una base de datos por documento de requisitos. ¿Cómo podemos modificar el esquema? ¿Cómo afecta a la BD? (ALTER TABLE) Diffs? Sincronización ?
• base de datos XML nativa, ver http://del.icio.us/erny1803/XMLDatabase. (Soporte para XMLSchema ?)
  • exist
  • xindice
• base orientada a objetos, tipo ZODB (ej. IndexedCatalog)